Dziwaczne nazwy tabel i kolumn w bazie MS SQL (korpo-style)

Być może będę musiał w pewnym projekcie pobierać dane z bazy - chyba - MS SQL (wszystko stoi na Windowsie). Moje dotychczasowe doświadczenie to języki skryptowe i unixy, zaś z baz MySQL, Postgres, Firebird, Mongo itp.

Bazę przygotowała duża, międzynarodowa korpo. Jej interfejsem jest desktopowa aplikacja na Windows. Dostałem na razie schemat bazy (bez jednocznacznej odpowiedzi co do silnika). Jestem w szoku.

Nazwy tabel w stylu: X07T1, R08T2
Nazwy pól x07bal (od balance), spfistat (single product costam status), tripef - (flaga o alertach podczas przewozu). Wybrałem lajtowe przykłady.

Brakuje mi jeszcze kilku lat doświadczenia, by jednoznacznie określić, czy to szajs, czy "pro". Jednak w świecie firm w których ja się obracam, bazy są tak projektowane, że nie potrzebują specjalnie dokumentacji - toczymy spory czy nazwać pole "created_on" (date) czy "created_at" (datetime) zamiast "date_created". W tej bazie to będzie jakieś "crdate".

Mam w związku z tym kilka pytań:

1. Skąd się biorą takie nazwy tabel i nazwy pół - czy to jakiś genialny MS-stack, który w połączeniu z C# tworzy abstrakcję bazy danych i automatycznie generuje np. xml'e jako data-mappery - programista w ogóle "olewa" nazwy tabel/kolumn w bazie? Coś w ten deseń?

2. Jak to jest możliwe, że w dużym korpo coś takiego przechodzi?

3. Czy spotykacie się z sytuacją j/w ?

4. Jakaś taktyka by sobie z tym poradzić (bez popadania w nałogi)?

Dzięki za pomoc!

Moim zdaniem albo robi to automat albo ktoś chciał sobie tam zapewnić pracę do końca życia. Nikt normalny dobrowolnie takich nazw nie używa.

1. Nie jest to na pewno żadne standardowe narzędzie Microsoftu w domyślnej konfiguracji. Możliwe, że użyto jakiegoś dziwnego ORMa, który tak zrobił, ale dużo bardziej prawdopodobne jest, że ktoś tak tę bazę zaprojektował. Takie podejście do nazewnictwa jest częste po pierwsze wśród starszych programitstów/archiektów, a po drugie za granicą.
2. Odpowiedź w pytaniu: "duże korpo".
3. Tak, w przypadku baz danych z zachodu jest tak często. Bez względu na to, czy to bazy MSSQL Server czy Oracle, codziennie widzę tabele w rodzaju: T_ABC_XYZPRDSPRT.
4. Zmienić pracę. ;)

Z mojego doświadczenia:

1. System ewoluował z jakiegoś przedpotopowego systemu bazodanowego, gdzie były ograniczenia co do długości nazw tabel i pól (np. ADABAS, DBase, ...) i wtedy faktycznie trzeba się wysilić, by zrobić w miarę unikalną nazwę.
2. Wystarczy napisać odpowiednią specyfikację i ją zatwierdzić :) I przyszłe pokolenia muszą się do niej stosować..
3. Tak. Choć aktualnie to raczej ja piszę specyfikacje z pkt 2 więc raczej NIE.
4. Przyzwyczaić się, zmienić pracę, utworzyć alias, view etc...

Dzięki za dotychczasowe odpowiedzi!

Obecnie daję 50/50 między mssql a oracle.

Po krótkiej kwerendzie w necie nt. wykonawcy zaczynam się zastanawiać, czy takie podejście nie jest celowe i ma zatrzymać klienta przy autorskiej firmie. Mają oddziały we wszystkich krajach w których przeprowadzili wdrożenia i w każdym przypadku, gdy dodatkowy, zintegrowany moduł (np. CRM) miał dostawić inny podmiot, to autorska firma bardzo chętnie dopisywała moduł integracji który wypychał dane do kolejnej bazy pośredniczącej - pewnie bardziej przejrzystej.

Mimo wszystko wizerunek takiego super-korpo działa i w pierwszej kolejności zarzucam sobie brak doświadczenia (jakby brak przejrzystych nazw zagmatwanie struktury był wyznacznikiem poziomu "enterprise").

Omawiane zadanie to na szczęście ewentualne dodatkowe zlecenie (duża odpowiedzialność umowna, gwarancja itp). Ciężko mi to zwyczajnie zlać, w końcu kiedy się nie brać za takie rzeczy jak nie teraz :) - ale ta baza wygląda przerażająco.

To na pewno nie jest poziom korpo enterprise. Jak już to jest jakieś badziewiarstwo.

@somekind

Takie podejście do nazewnictwa jest częste po pierwsze wśród starszych programitstów/archiektów, a po drugie za granicą.

Dlaczego?

@Wizzie, bo starsi są przyzwyczajeni do oszczędzania na znakach, a za granicą uważają, że wszystko musi być tak trudne, żeby bez instrukcji obsługi nie dało się używać.

Możliwe że baza (jej design) pochodzi jeszcze z COBOL-a.
Albo została zaprojektowana przy użyciu jakiegoś narzędzia które wyświetla dodatkowe opisy.

Zajrzyj tutaj:
http://www.timwappat.info/post/2011/01/24/Dynamically-fetching-column-names-and-meta-descriptions-TSQL

somekind napisał(a):

[...] za granicą uważają, że wszystko musi być tak trudne, żeby bez instrukcji obsługi nie dało się używać.

Miałem cień nadziei, że te nazwy tabel to jakaś konwencja przyjęta w dokumentacji. Niestety nie. Trafiłem na przykładowe zapytania - aplikacja umożliwa też ręczne wprowadzanie zapytań ;)

select [...] from L00T2 join L30T1 on L00T2 [...]

System podobno powstał w latach 70-tych i potem powoli ewoluował - pewnie głównie pod względem UI. Teorie o prastarej architekturze bazy są chyba trafione.

Jeszcze raz dzięki za wszystkie odpowiedzi!

To jest klasyka, chyba zwłaszcza w Niemieckich systemach. ;)
Patrz np. system SAP:
http://www.recercat.cat/bitstream/handle/2072/5419/PFCLopezRuizAnnex3.pdf?sequence=4