Мій колега створив таблицю SQL 96 колонок

23

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

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

І все-таки я розумію, що "Це стане простіше".

Що я повинен зробити?

Редагувати *

Ця таблиця містить дані датчиків.
У нас є датчик 1 з
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Ну, я нарешті залишив цю роботу. Це ознака, коли інший програміст темніє місяцями в той час, це ще одна ознака, коли керівництво не усвідомлює, що це проблема

sql code-smell

— Ерік
джерело

5

Фу, може бути і темних віків. Коли люди навчаться користуватися базами даних?

— ChaosPandion

49

Яка ваша альтернатива? Ви не можете просто переживати через проблему, якщо у вас немає рішення.

— TGnat

1

Мені цікаво, що зберігається в кожному рядку.

— MetalMikester

1

@ChaosPandion, лише черездовго після використання традиційних баз даних саме по собі дизайнерський запах.

— instanceofTom

3

Ну, він чітко переосмислює вашу базу даних. Раніше ми мали базу даних з єдиною таблицею з лише 4 стовпчиками вархар: CLASS, OBJECT, ATTRIBUTE, VALUE. Усі дані вміщуються там. Бий це! :)

— Лукаш Едер

32

Можливо, він зробив це з вагомих причин, наприклад, виступів або ROI? .

Найкраще, що потрібно зробити, - це задавати йому питання. З певною кількістю «чому» ви неодмінно дасте йому зрозуміти, що він, мабуть, помиляється сам по собі (якщо він є насправді).

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

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

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

У нас буде багато можливостей покращити це в майбутньому. Час на ринок був пріоритетним для нас у той час.

3

Я погоджуюсь - без додаткового контексту до "чому" кількість стовпців насправді не має значення. Можна законно відстежувати 96 речей ... або, можливо, він використовує додаткові стовпці для 'масивів' даних (name_1, name_2), які слід розбити на інші таблиці.

— GrandmasterB

О, ти

1

"нормалізований" не обов'язково означає "добре розроблений". Я вважаю денормалізацію, яку ви описуєте тут, ідеально чудовим дизайнерським рішенням.

1

Я повністю згоден з @GrandmasterB. Кількість стовпців - це не те, про що можна судити самостійно. Бувають випадки, коли про одну річ потрібно зберігати велику кількість суміжних даних. Що робити людям? Складіть таблицю з тегами даних (id, tag, value)і INSERTдев'яносто непарних рядків? Якщо інформація належить до таблиці і є виправданою, то стовпець залишається, якщо тільки це не викликає жахливих проблем продуктивності.

— Орлінг

+1 Денормалізація необхідна для певних програм. Я б заперечував, що бази даних не є електронними таблицями. Тільки тому, що вони мають подібний формат таблиці, не обов'язково означає, що бази даних повинні бути зрозумілими для людини. Вони є резервним сховищем даних і їх слід розглядати як такі.

— Еван Плейс

17

На жаль, середній розробник все ще вважає реляційні бази даних великими плоскими файлами. Єдиний спосіб, коли вони стануть кращими, це якщо хтось візьме на себе відповідальність і приведе на приклад. Нещодавно я очолив капітальний перегляд важливої схеми в нашій базі даних та дотримувався загальних реляційних практик. Раптом наші зберігаються процедури були більш елегантними, і всі належні покажчики, здавалося, стали на місце так, ніби вони народилися для цього. Розробник, керований егою, ніколи не повірить вам без доказів.

— ChaosPandion
джерело

2

Іноді потрібні докази, щоб переконати того, хто вже впевнений, що має рацію. +1

— Кріс

1

Дійсно? Середній розробник робить це? Yikes.

— webbiedave

Можливо, великі плоскі файли - це те, що їм потрібно в першу чергу;)?

— Робота

не обов’язково его, але навіщо вам змінюватися? Новий матеріал повинен бути набагато краще "заплатити" за витрачений час і зусилля на його використання.

-1 є цілком поважні причини використання таблиці денормалізованих даних. Наприклад, що робити, якщо вам потрібно було розподілити його на багатьох серверах, оскільки набір даних зростав занадто великим або вам потрібен надзвичайно низький час затримки доступу (скажімо до побачення з використанням приєднань).

— Еван Плейс

11

Щось подібне обговорювалося раніше на StackOverflow .

Взагалі, наявність стовпців на столі не обов'язково означає, що ви щось робите не так, але це, безумовно, повинно підняти червоні прапори, щоб ви уважно придивились до дизайну. Іноді величезний стіл - це правильний вибір, але у багатьох випадках інші альтернативи мають більше сенсу. Наприклад, одним із варіантів є поділ пам’яті на дві таблиці: одна таблиця, яка ідентифікує ваші сутності, та інша таблиця, яка фактично зберігає ключ / значення атрибутів, що описують ці сутності (так що у вас може бути не більше 96 рядківдля кожного суб'єкта). Можливі й інші конструкції. Поговоріть зі своїми товаришами по команді та з’ясуйте, яке рішення краще залежно від нормалізації даних, читабельності коду та ремонтопридатності (вставити заяви з 96 атрибутами для заповнення?), Наслідки щодо продуктивності, як часто можна додавати чи змінювати нові атрибути (стовпці), наскільки рідкісні дані є (скільки з 96 стовпців коли-небудь буде заповнено, а скільки залишиться NULL?), а також наслідки щодо звітності. Будь-який розробник повинен мати можливість обґрунтовано обґрунтовувати свої дизайнерські рішення та показати, що компроміс витрат / вигод (і так, кожне дизайнерське рішення є компромісом) йде на їх користь. Ваша відповідальність полягає не в тому, щоб скаржитися чи критикувати, а пропонувати альтернативи та переконатися, що вони продумали ці питання.

— Євгеній Брікман
джерело

1

Магазини ключових цінностей майже не допускають найгіршого вибору для продуктивності та доказовості.

— HLGEM

8

Хочете допрацювати?

— Євгеній Брікман

9

Це нормалізується за допомогою 96 стовпців? Чи задовольняє вона 1-й, 2-й, 3-й тощо НФ?

Можливо, у вас є 96 окремих атрибутів для сутності.

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

— гбн
джерело

5

Це повністю залежить.

Нормалізовані / ненормалізовані конструкції БД мають і свої переваги, і недоліки.

Моя перша конструкція БД була нормалізованою справою краси. Він був гнучким і розтяжним. Це був також неймовірний PITA для будь-кого, окрім мене, для вирішення на рівні коду, і це було м'яким ПДФО для мене.

Моя наступна спроба була плоскою структурою, і це було (а) набагато швидше і (б) набагато простіше кодувати. І пізніше нормалізація не буде великою справою.

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

— Джон
джерело

+1 Зазначивши, що часто немає правильного шляху.

— Увімкнення

3

Запропонуйте йому прочитати цю статтю про технічну заборгованість . Якщо він все-таки вирішить зберегти це таким чином, то, принаймні, ви запропонували конструктивну думку.

— БредБ
джерело

1

Дивлячись на (відредаговану) публікацію, зрозуміло, що це погано денормалізована таблиця. Що тобі слід робити? Як я бачу, у вас є кілька варіантів:

Погляньте на свого колегу, щоб навчитися виконувати свою роботу. Навряд чи буде продуктивним, але, ймовірно, переконає інших колег не возитися з вами. Репутація кричущого маніяка може бути корисною (не питайте мене, як я знаю).
Кричать на боса, що колега - ідіот. Прогнозуйте катастрофу, потім активно працюйте над диверсійним проектом. Звинувачуйте все в розробці бази даних, виготовленої некомпетентним колегою. Може призвести безпосередньо до ...
Вийдіть. Найкраще, якщо це ваша ідея, але №2 може призвести до мимовільної відставки. Постарайтеся не колупати коліна асфальтом / бетоном / гравієм, якщо з-під вікна розлючений бос та / або колеги з нього віяли з вікна. (Зверніть увагу, що попереднє дослідження тут ВАЖЛИВО. Ваші шанси на виживання помітно знижуються, якщо офіс начальства знаходиться над першим поверхом, і ви виявите, що вас тілесно просувають через вікно. Плануйте заздалегідь !! )
Випивайте сильно - або рухайтеся до Каліфорнії та запалюйте (якщо припустити пропуск 19 (або що завгодно)). Нічого, як кілька кадрів і дубі, щоб поліпшити погляд на колег (або я так чув). (Оголошення громадської служби: ДІТИ! Ці люди є професіоналами! НЕ пробуйте цього вдома!)

Діліться та насолоджуйтесь.

— Боб Джарвіс - Відновлення Моніки
джерело

Я спробував №4, але зараз настає понеділок, і все повернеться, коли я дойду до робочого місця =)

— Ерік

Прочитайте перший пункт. Отримано. Прочитайте пункт другий, скасуйте мою підсумку. Серйозно, чувак?

— Зоран Павлович

0

Я збираюся вийти на кінцівку тут і припускаю, що він збирається вирізати і вставити багато коду для роботи з цією «новою» таблицею.

Якщо це так, ви, ймовірно, не матимете додаткових технічних боргів. Він просто розділив свою частку технічного боргу і може бути на шляху до якогось грандіозного об'єднання речей.

Якщо у нього є якась випробувана і правдива методологія, яка вимагає 96-стовпчикової речі, розгляньте фактичні переваги її виконання в іншому випадку. Якщо таких немає, то надавайте йому користь сумніву, але нагадуйте йому, що наступного разу, коли ви захочете опинитися на етапі планування, наступного разу, коли він зробить те, що ми всі вважаємо досить німим кроком.

— Пітер Тернер
джерело

0

Залежить повністю від випадків використання програми, яка збирається отримати доступ до схеми, який фрагмент даних потрібен одночасно. Якимось чином це може виправдати дизайн столу.

— SJha
джерело

0

Я б надіслав його до кам'яних віків і змусив би його використовувати файли або принаймні навчити його користуватися краплями.

Дійсно, 96колонок ... Це не може бути правильним, коли-небудь. Можливо, ОРМ допоможе. (Якщо вам не потрібна продуктивність, але тоді ви можете мати когось, хто розуміє БД, краще впоратися з нею)

0

Я зважаю на це все, до пекла, але саме тому я розділив обов'язки моделювання даних та інженерії програмного забезпечення в своєму магазині. Програмістам рідко здається, що вони думають у формах наборів і натомість зосереджуються на використанні даних (а не на підтримці 3-ї нормальної форми, індексації чи інших проблем продуктивності БД). Ми, як програмісти, також схильні більше не погоджуватися щодо тих архітектурних рішень БД, ніж ми, можливо, повинні, грунтуючись на нашому досвіді в чистому моделюванні даних / архітектурних питаннях. ІМХО, мені подобається, що у мене є архітектори даних та модельєри, які вимагають вимог, будують таблиці / програми / і т.д., і залишають мені справу з результатами.

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

— iivel
джерело