Mój współpracownik utworzył 96-kolumnową tabelę SQL

Jesteśmy w 2010 roku, inżynierowie oprogramowania z 4 lub 5 lat lub doświadczeniem, wciąż projektujący stoły z 96 kolumnami szczelinowania.

Powiedziałem mu, że to będzie koszmar.
Pokazałem mu, że musimy użyć porządków by połączyć MySQL z C #.
Wyjaśniłem, że tabele zawierające więcej kolumn niż wierszy mają ogromny zapach.

Mimo to otrzymuję komunikat „W ten sposób będzie łatwiej”.

Co powinienem zrobić?

EDYTOWAĆ *

Ta tabela zawiera dane z czujników.
Mamy czujnik 1 z
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDYCJA 2 *

W końcu porzuciłem tę pracę. To znak, że drugi programista ciemnieje przez wiele miesięcy w tym czasie, to kolejny znak, gdy kierownictwo nie zdaje sobie sprawy, że to problem

Może zrobił to z dobrych powodów, takich jak występy lub zwrot z inwestycji? .

Najlepiej zadać mu pytania. Z pewną ilością „dlaczego” na pewno sprawisz, że zrozumie, że prawdopodobnie sam się myli (jeśli naprawdę tak jest).

Miałem jeden przypadek, który nie jest związany z wynikami, ale zwrotem z inwestycji (ROI). Miałem tabelę zawierającą obiekty, które miały określoną wartość dla każdej godziny tygodnia (168 godzin w tygodniu). Mieliśmy wybór, aby utworzyć tabelę ObjectHour, która zawierałaby wartość, ale także klucz do obiektu i liczbę dni w liczbie godzin. Ale mieliśmy również możliwość ustawienia 168 wartości bezpośrednio w rzędzie. Prawdopodobnie podoba się to, co zrobił twój przyjaciel.

Deweloperzy ocenili oba rozwiązania. Proste rozwiązanie (168 kolumn) było o wiele tańsze niż jego dobrze zaprojektowany odpowiednik. Dla dokładnie takiego samego wyniku dla klienta.

Zdecydowaliśmy się na proste / najtańsze rozwiązanie, aby skoncentrować nasze wysiłki na ważniejszych kwestiach, takich jak bezpieczeństwo.

W przyszłości będziemy mieli wiele okazji, aby to poprawić. Czas na rynek był wówczas dla nas priorytetem.

Niestety przeciętny programista nadal uważa relacyjne bazy danych za duże pliki płaskie. Jedynym sposobem, aby uzyskać lepsze, jest to, że ktoś przejmie dowodzenie i da przykład. Niedawno stałem na czele poważnego przeprojektowania ważnego schematu w naszej bazie danych i postępowałem zgodnie z powszechnymi praktykami relacyjnymi. Nagle nasze procedury składowane stały się bardziej eleganckie, a wszystkie właściwe indeksy wydawały się pasować, jakby zostały stworzone do tego. Twórca napędzany ego nigdy nie uwierzy ci bez dowodu.

Coś podobnego zostało wcześniej omówione na StackOverflow .

Ogólnie rzecz biorąc, posiadanie wielu kolumn na stole niekoniecznie oznacza, że ​​robisz coś źle, ale zdecydowanie powinno podnieść kilka czerwonych flag, aby dokładnie przyjrzeć się projektowi. Czasami właściwym wyborem jest ogromny stół, ale w wielu przypadkach inne alternatywy mają większy sens. Na przykład jedną z opcji jest podzielenie pamięci na dwie tabele: jedną tabelę, która identyfikuje twoje jednostki, i drugą tabelę, która jest faktycznie magazynem kluczy / wartości atrybutów opisujących te jednostki (więc możesz skończyć z maksymalnie 96 wierszamidla każdego podmiotu). Możliwe są również inne projekty. Porozmawiaj z kolegami z zespołu i dowiedz się, które rozwiązanie jest lepsze w zależności od normalizacji danych, czytelności kodu i łatwości konserwacji (wstaw instrukcje z 96 atrybutami do wypełnienia?), Wpływ na wydajność, jak często nowe atrybuty (kolumny) mogą być dodawane lub zmieniane, jak rzadkie dane to (ile z 96 kolumn zostanie kiedykolwiek wypełnionych, a ile pozostanie NULL?) i wpływ na raportowanie. Każdy programista powinien być w stanie racjonalnie uzasadnić swoje decyzje projektowe i wykazać, że kompromis koszt / korzyść (i tak, każda decyzja projektowa jest kompromisem) na ich korzyść. Twoim obowiązkiem nie jest narzekać ani krytykować, ale proponować alternatywy i upewnić się, że przemyśleli te kwestie.

Czy jest znormalizowany przy użyciu 96 kolumn? Czy spełnia 1., 2., 3. itd. NF?

Możliwe, że masz 96 osobnych atrybutów dla encji.

W przeciwnym razie każ mu przeczytać Joe Celko w Simple Talk

To całkowicie zależy.

Znormalizowane / nienormalizowane projekty DB mają zarówno zalety, jak i wady.

Mój pierwszy projekt DB był znormalizowaną rzeczą piękna. Był elastyczny i rozszerzalny. Była to również niesamowita PITA dla każdego oprócz mnie, która radziła sobie na poziomie kodu, i była to dla mnie łagodna PITA.

Moja kolejna próba była płaską strukturą i była (a) dużo szybsza i (b) znacznie łatwiejsza do kodowania. Normalizacja później nie będzie wielkim obowiązkiem.

Może to być zapach, ale niektóre inne konstrukcje DB będą miały swój własny zachwycający zestaw zapachów.

Poproś go, aby przeczytał ten artykuł o zadłużeniu technicznym . Jeśli nadal zdecyduje się zachować to w ten sposób, to przynajmniej zaproponowałeś konstruktywną opinię.

Patrząc na (zredagowany) post, jasne jest, że jest to źle zdormalizowana tabela. Co powinieneś zrobić? Widzę, że masz kilka opcji:

1. Krzycz na swojego współpracownika, aby dowiedzieć się, jak wykonywać swoją pracę. Jest mało prawdopodobne, aby był produktywny, ale prawdopodobnie przekona innych współpracowników, aby nie zadzierali z tobą. Przydatna może być reputacja krzyczącego maniaka (nie pytaj mnie, skąd to wiem).
2. Krzycz szefowi, że współpracownik jest idiotą. Przewiduj katastrofę, a następnie aktywnie pracuj nad projektem sabotażowym. Obwiniaj wszystko za projekt bazy danych wyprodukowany przez niekompetentnego współpracownika. Może prowadzić bezpośrednio do ...
3. Porzucić. Najlepiej, jeśli to twój pomysł, ale # 2 może doprowadzić do mimowolnej rezygnacji. Staraj się nie ocierać kolan o asfalt / beton / żwir, jeśli zostanie wyrzucony z okna przez rozwścieczonego szefa i / lub współpracowników. (Zwróć uwagę, że wcześniejsze badania są tutaj WAŻNE. Twoje szanse na przeżycie znacznie się zmniejszają, jeśli biuro szefów znajduje się nad parterem i okaże się, że jesteś wyrzucony przez okno. Zaplanuj !! )
4. Pij dużo - lub przenieś się do Kalifornii i zapal się (zakładając, że prop. 19 (lub cokolwiek) mija). Nie ma to jak kilka ujęć i doobie, aby poprawić swoje spojrzenie na współpracowników (a przynajmniej tak słyszałem). (Ogłoszenie usługi publicznej: DZIECI! Ci ludzie to profesjonaliści! NIE próbuj tego w domu!)

Udostępnij i ciesz się.

Mam zamiar wyjść tutaj na całość i założyć, że wytnie i wklei dużo kodu do pracy z tym „nowym” stołem.

Jeśli tak, prawdopodobnie nie poniesiesz żadnego dodatkowego długu technicznego. Właśnie podzielił swoją część długu technicznego i może być na dobrej drodze do jakiegoś wielkiego zjednoczenia rzeczy.

Jeśli ma wypróbowaną i prawdziwą metodologię, która wymaga 96-kolumnowej rzeczy, weź pod uwagę rzeczywiste korzyści z zrobienia tego inaczej w tym konkretnym przypadku. Jeśli ich nie ma, daj mu wątpliwości, ale przypomnij mu, że następnym razem, gdy będziesz chciał wziąć udział w fazie planowania, następnym razem zrobi to, co wszyscy uznalibyśmy za dość głupi ruch.

Zależy całkowicie od przypadków użycia aplikacji, która ma uzyskać dostęp do schematu, jaka część danych jest potrzebna w danym momencie. W pewien sposób może to uzasadnić projekt tabeli.

Posłałbym go do epoki kamienia łupanego i zmusiłbym do korzystania z plików lub przynajmniej nauczyłem go, jak używać kropelek.

Naprawdę, 96 kolumn ... Nie mogę mieć racji, nigdy. Może ORM by pomógł. (Chyba że potrzebujesz wydajności, ale możesz mieć kogoś, kto lepiej rozumie DB, aby sobie z tym poradzić)

Zostanę za to pochłonięty piekłem, ale właśnie dlatego w moim sklepie rozdzieliłem obowiązki związane z modelowaniem danych i inżynierią oprogramowania. Programiści rzadko wydają się myśleć w formie zestawów i zamiast tego koncentrują się na wykorzystaniu danych (zamiast utrzymywać trzecią normalną formę, indeksowanie lub inne problemy z wydajnością bazy danych). My, programiści, również nie zgadzamy się bardziej na te decyzje architektoniczne DB niż być może powinniśmy, w oparciu o nasz brak doświadczenia w czystym modelowaniu danych / zagadnieniach architektonicznych. IMHO, podoba mi się to, że mam architektów i projektantów danych, którzy biorą wymagania, budują tabele / procs / etc. I pozostawiam zarządzanie wyjściami.

Nie znając jednak rzeczywistych przyczyn tego projektu (pracowałem nad czujnikami pogodowymi, które mają znacznie więcej niż 96 różnych wyjść numerycznych = duża liczba kolumn tabeli) ... to po prostu wydaje się odpowietrzać zwierzaka.