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

23

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

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

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

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

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

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

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

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

Эрик
источник
5
Тьфу, могут быть и темные века. Когда люди научатся пользоваться базами данных?
ChaosPandion
49
Какая у вас альтернатива? Вы не можете просто раздражаться из-за проблемы, если у вас нет решения.
TGnat
1
Мне интересно, что хранится в каждом ряду.
MetalMikester
1
@ChaosPandion, только долгое время после использования традиционных баз данных сам по себе является запахом дизайна.
экземпляр с
3
Ну, он явно перегружает вашу базу данных. Раньше у нас была база данных с одной таблицей, состоящей всего из 4 столбцов varchar: CLASS, OBJECT, ATTRIBUTE, VALUE. Все данные вписываются туда. Бить это! :)
Лукас Эдер

Ответы:

32

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

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

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

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

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

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


источник
3
Я согласен - без дополнительного контекста «почему» количество столбцов действительно не имеет значения. На законных основаниях может отслеживаться 96 вещей ... или он может использовать дополнительные столбцы для «массивов» данных (name_1, name_2), которые должны быть разбиты на другие таблицы.
GrandmasterB
О, ты заставляешь меня вспомнить одну вещь ... Я добавлю это к своему ответу
1
«нормализованный» не обязательно означает «хорошо спроектированный». Я бы посчитал описанную здесь денормализацию идеальным решением для дизайна.
1
Я полностью согласен с @GrandmasterB. Количество столбцов - это не то, что можно судить независимо. Есть моменты, когда большое количество связанных данных должно храниться об одной вещи. Что должны делать люди? Сделать таблицу данных с тегами (id, tag, value)и INSERTдевяносто лишних строк? Если информация принадлежит таблице и является обоснованной, то столбец остается, если только он не вызывает ужасную проблему производительности.
Orbling
+1 Денормализация необходима для определенных приложений. Я бы сказал, что базы данных не являются электронными таблицами. Тот факт, что они имеют похожий формат таблиц, не обязательно означает, что базы данных должны быть удобочитаемыми. Они являются внутренним хранилищем данных и должны рассматриваться как таковые.
Эван Плейс
17

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

ChaosPandion
источник
2
Иногда требуются доказательства, чтобы убедить кого-то, кто уже убежден, что они правы. +1
Крис
1
В самом деле? Средний разработчик делает это? Хлоп.
webbiedave
Возможно, большие плоские файлы - это то, что им нужно в первую очередь;)?
Работа
не обязательно эго, но почему вы должны измениться? Новые вещи должны быть намного лучше, чтобы «заплатить» за время и усилия, потраченные на его использование.
-1 есть совершенно веские причины для использования денормализованной таблицы данных. Например, что делать, если вам нужно разделить его на многих серверах, потому что набор данных стал слишком большим или вам требуется чрезвычайно малое время ожидания (попрощайтесь с использованием объединений).
Эван Плейс
11

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

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

Евгений Брикман
источник
1
хранилища ключевых ценностей почти всегда являются худшим выбором для производительности и опроса.
HLGEM
8
Хотите разработать?
Евгений Брикман
9

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

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

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

ГБН
источник
5

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

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

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

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

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

Джон
источник
+1 За указание на то, что часто нет правильного пути.
Orbling
3

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

BradB
источник
1

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

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

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

Боб Джарвис - Восстановить Монику
источник
Я пробовал # 4, но сейчас понедельник, и все вернется, когда я доберусь до места работы =)
Эрик
Прочтите первый пункт. Upvoted. Прочтите пункт два, отмените мое возражение. Серьезно, чувак?
Зоран Павлович
0

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

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

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

Питер Тернер
источник
0

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

SJha
источник
0

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

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


источник
0

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

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

iivel
источник