Мой коллега создал таблицу SQL на 96 столбцов

Здесь мы в 2010 году, инженеры-программисты с 4 или 5 годами или опытом, все еще разрабатывающие таблицы с 96 колоннами фракционирования.

Я сказал ему, что это будет кошмар.
Я показал ему, что мы должны использовать ординалы для взаимодействия MySQL с C #.
Я объяснил, что таблицы с большим количеством столбцов, чем строк - это огромный запах.

Тем не менее, я получаю "Это будет проще".

Что мне делать?

РЕДАКТИРОВАТЬ *

Эта таблица содержит данные от датчиков.
У нас есть датчик 1 с
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Ну, я наконец-то оставил эту работу. Это признак, когда другой программист темнеет в течение нескольких месяцев, это еще один признак, когда руководство не осознает, что это проблема

Может быть, он сделал это по уважительной причине, например, выступления или ROI? ,

Лучше всего задавать ему вопросы. С определенным количеством «почему» вы непременно заставите его понять, что он, вероятно, ошибается сам по себе (если он действительно так).

У меня был один случай, который связан не с показателями, а с окупаемостью инвестиций (ROI). У меня была таблица, содержащая объекты, которые имели определенное значение для каждого часа недели (168 часов в неделю). У нас был выбор - создать таблицу ObjectHour, которая будет содержать значение, а также ключ к объекту и номер дня в номере часа. Но у нас также была возможность поставить 168 значений прямо в ряд. Наверное, как то, что сделал ваш coleague.

Разработчики оценили оба решения. Простое решение (168 столбцов) было намного дешевле, чем его хорошо продуманный аналог. Точно такой же результат для клиента.

Мы решили выбрать простое / дешевое решение, чтобы сосредоточить усилия на более важных вещах, таких как безопасность.

У нас будет много возможностей улучшить это в будущем. Время выхода на рынок было для нас приоритетом.

К сожалению, ваш средний разработчик все еще считает реляционные базы данных большими плоскими файлами. Единственный путь, которым они будут становиться лучше, - это если кто-то возьмет на себя ответственность и подаст пример. Совсем недавно я инициировал серьезную переработку важной схемы в нашей базе данных и следовал общепринятым реляционным практикам. Внезапно наши хранимые процедуры стали более элегантными, и все надлежащие индексы, казалось, встали на свои места, как будто они были созданы для этого. Разработчик, движимый эго, никогда не поверит вам без доказательств.

Нечто подобное обсуждалось ранее на StackOverflow .

В общем, наличие большого количества столбцов в таблице не обязательно означает, что вы делаете что-то не так, но это определенно должно поднять некоторые красные флажки, чтобы вы присматривались к дизайну. Иногда огромный стол является правильным выбором, но во многих случаях другие альтернативы имеют больше смысла. Например, один из вариантов - разделить хранилище на две таблицы: одну таблицу, которая идентифицирует ваши сущности, и другую таблицу, которая фактически является хранилищем ключей / значений атрибутов, описывающих эти сущности (так что вы можете получить не более 96 строкдля каждого субъекта). Возможны и другие варианты дизайна. Поговорите со своими товарищами по команде и выясните, какое решение лучше в зависимости от нормализации данных, читабельности кода и удобства сопровождения (вставьте операторы с 96 атрибутами для заполнения?), Влияний на производительность, как часто можно добавлять или изменять новые атрибуты (столбцы), насколько редко данные (сколько из 96 столбцов будет когда-либо заполнено и сколько осталось NULL?) и влияние на отчетность. Любой разработчик должен быть в состоянии обоснованно обосновать свои дизайнерские решения и показать, что компромисс между затратами и выгодами (и да, каждое проектное решение - компромисс) в их пользу. Ваша обязанность состоит не в том, чтобы жаловаться или критиковать, а в том, чтобы предлагать альтернативы и убедиться, что они продумали эти проблемы.

Нормализовано с 96 колонками? Удовлетворяет ли это 1-й, 2-й, 3-й и т. Д. НФ?

Возможно, у вас есть 96 отдельных атрибутов для объекта.

В противном случае, заставьте его прочитать Джо Селко на Simple Talk

Это полностью зависит.

Нормализованные / ненормализованные конструкции БД имеют свои преимущества и недостатки.

Мой первый дизайн БД был нормой красоты. Это было гибко и расширяемо. Кроме того, для каждого, кроме меня, было невероятным PITA иметь дело на уровне кода, и это была мягкая PITA для меня.

Моей следующей попыткой была плоская структура, и она была (а) намного быстрее и (б) намного проще в коде. И это не будет огромной рутиной, чтобы нормализовать больше позже.

Так что это может быть запах, но у некоторой другой конструкции БД будет свой восхитительный набор запахов.

Заставьте его прочитать эту статью о техническом долге . Если он все же решит оставить это так, то, по крайней мере, вы предложили конструктивное мнение.

Глядя на (отредактированный) пост, становится ясно, что это плохо денормализованная таблица. Что вы должны сделать? На мой взгляд, у вас есть несколько вариантов:

1. Кричите на своего коллегу, чтобы узнать, как выполнять свою работу. Маловероятно, чтобы быть продуктивным, но, вероятно, убедит других сотрудников не связываться с вами. Может пригодиться репутация кричащего маньяка (не спрашивайте меня, откуда я знаю).
2. Кричать на босса, что коллега идиот. Прогнозировать катастрофу, затем активно работать над саботажем проекта. Во всем виноват проект базы данных, созданный некомпетентным сотрудником. Может привести непосредственно к ...
3. Уволиться. Лучше всего, если это ваша идея, но № 2 может привести к вынужденной отставке. Постарайтесь не поцарапать колени на асфальте / бетоне / гравии, если выскочил из окна разъяренный босс и / или коллеги. (Обратите внимание, что предварительное исследование ВАЖНО здесь. Ваши шансы на выживание заметно уменьшаются, если офис босса находится над первым этажом, и вы обнаруживаете, что вас выталкивают из окна. Планируйте заранее !! )
4. Пейте много - или переезжайте в Калифорнию и зажигайте свет (при условии, что проп. 19 (или что-то еще) проходит). Ничего подобного нескольким выстрелам и ребёнку, чтобы улучшить взгляд на своих коллег (или, как я слышал). (Объявление о государственной службе: ДЕТИ! Эти люди профессионалы! НЕ пытайтесь делать это дома!)

Поделитесь и наслаждайтесь.

Я собираюсь выйти на конечность и предположить, что он собирается вырезать и вставить много кода для работы с этой «новой» таблицей.

Если это так, вы, вероятно, не будете нести никаких дополнительных технических долгов. Он просто разделил свою долю технического долга и может быть на пути к какому-то великому объединению вещей.

Если у него есть какая-то проверенная и верная методология, которая требует 96 столбцов, подумайте о реальных выгодах от этого в данном конкретном случае. Если их нет, то дайте ему преимущество сомнения, но напомните ему, что в следующий раз, когда вы захотите быть на этапе планирования, в следующий раз, когда он сделает то, что мы все считаем довольно глупым ходом.

Полностью зависит от сценариев использования приложения, которое будет обращаться к схеме, какой кусок данных требуется за один раз. В некотором смысле это может оправдать дизайн таблицы.

Я отправляю его в каменные века и заставляю его использовать файлы или, по крайней мере, учить его, как использовать капли.

Действительно, 96 колонн ... Это не может быть правдой, никогда. Может быть, ORM поможет. (Если вам не нужна производительность, но у вас может быть кто-то, кто лучше понимает БД, чтобы справиться с этим)

Я собираюсь все понизить за это, но именно поэтому я разделил обязанности моделирования данных и разработки программного обеспечения в своем магазине. Программисты редко думают в форме наборов и вместо этого сосредотачиваются на использовании данных (вместо того, чтобы поддерживать третью нормальную форму, индексирование или другие проблемы с производительностью БД). Мы, как программисты, также склонны больше соглашаться с этими архитектурными решениями БД, чем, возможно, следовало бы, исходя из нашего неопытности в вопросах моделирования данных / архитектуры. ИМХО, мне нравится, что у меня есть архитекторы данных и разработчики моделей, которые берут требования, строят таблицы / процессы / и т. Д. И оставляют на усмотрение результаты.

Хотя, не зная фактических причин такого дизайна (я работал с датчиками погоды, которые имеют более 96 различных числовых выходов = большое количество столбцов таблицы) ... это просто похоже на проветривание любимой мозоли.