[apo]

#programista15k #bazydanych #sql
Programiści nie potrafią w bazy danych.

Kawusia, połączenie do nowego projektu, a tam:
MobileApplicationName VARCHAR(8000)
MobileApplicationID VARCHAR(8000)

Nazwa aplikacji na 2 strony w Wordzie. I tak praktycznie każda kolumna.
Na kolumnach całkowity brak ograniczeń,indeksów, relacji.
Naście lat w tym biznesie i za każdym razem to samo [:

[apo]

@RomantycznyRoman: Dokładnie. Widok na widoku, często nazwy tak odlatują, ze ktoś nawet nie wie i robi self join do źródłowych danych. Widzę kolega doskonale rozumie specyfikę tej pracy w przeciwieństwie do @rosso_corsa ;)

@masaj: Dobre XD ale w sumie mogę spróbować, widziałem VARCHAR(5) dwa stany, 'TRUE','FALSE', zapisane w dowolny sposób wliczając spacje. O ile SQL Server ignoruje rozmiar to już inne systemy płaczą.
I żeby było ciekawiej funkcja która to

[apo]

@masaj: Czytałeś jak wygląda kod Oracle od środka?;) https://www.wykop.pl/link/5195759/najwieksza-ilosc-zlego-kodu-w-jednym-miejscu-czyli-praca-z-oracle-database/

[masaj]

@apo: Boje się tam zaglądać ;)

[apo]

@masaj: [:
@globalbus Niestety ale nawet przy braku problemów z wydajnością w dzisiejszym świecie bazy nie istnieją w zamkniętej przestrzeni, ktoś to w końcu zaimportuje. ;) Nawet z racji weryfikacji danych i poprawności warto te pola ograniczać. Do tego jak pracujesz na danej bazie fajnie byłoby jednak znać jej specyfikacje ;)

Twórcy postgresql sami zachęcają do używania typów bez rozmiaru, co jest wygodne, ale kłóci się z jakością, integralnością itd. ;)

[edgar_k]

@apo: no i zapewne czas jaki poświęciłeś na te rozkminy i naprawy kosztował dużo więcej niż strata wydajności serwera przez ostatnie 5 lat + koszty stażysty
To jest dopiero problem

[globalbus]

@apo: właśnie to, że ktoś wpisał te długości z dupy jest kwestią wtórną źle zaprojektowanego systemu. Tuning pod konkretną bazę danych to późniejsza faza.

Jeśli chodzi o temat postgresql i indeksy, to już jest gruby temat i wykracza poza moje kompetencje. Tam można różne ciekawe sztuczki robić.

[Antyradek]

@apo: Mamy 2020 rok, a bazy danych nadal wymagają stałych wielkości pól tekstu.

[apo]

@edgar_k: Patrząc na czasy zapytań i koszt tych wszystkich pracowników przez 5lat+ siedzących na tyłku czekając na raport to zdecydowanie nie więcej ich kosztowało i dzięki mnie oszczędzają. Tak dla przykładu jedna tabela po optymalizacji z 190GB na 6GB, zapytania po 12 minut na sekundy.

@Antyradek: 2020 ludzie nadal nie rozumieją dlaczego nazwa aplikacji powinna mieć jakiś limit długości ;) Fakt postgresql ma fajne rozwiązanie, już o tym napisałem, ale

[dnkej]

@apo: Panie apo, chce od Pana się uczyć

[wafel93]

@apo: jak to możliwe, że objętość spadła ze 190 GB na 6? Pytam z ciekawości

[ShortyLookMean]

objętość spadła ze 190 GB na 6

@wafel93: brzmi niemal jak optymalizacja przez DROP.

[apo]

@ShortyLookMean: @dnkej: @wafel93: Columnstore z kompresją + zamiana codziennego snapshotu wszystkich danych na na SCD, Trzymali koszmarnie nadmiarową ilość danych,która dodatkowo niewiele się różniła między 1 a drugim dniem. Brakowało też indeksów, a tak pyknęło wszystko na raz.

Tutaj masz ciekawy opis tego: https://pl.seequality.net/columnstore-index-mechanizmy-kompresji/ .
Z 3GB na 180MB.

[ms86]

@apo niestety obecnie latwiej i taniej (jako jednorazowy koszt) jest dolozyc ramu (a nawet cpu) niz zainwestowac w optymalizacje, ktora w dluzszym czasie bedzie wieksza oszczednoscia ¯_(ツ)_/¯

8k znakow na nazwe aplikacji jest mega zastanawiajace ...

[apo]

@ms86: W sumie to zależy od kosztów. Kiedyś walczyłem o optymalizacje, bo miesięcznie na serwery szło po 60kUSD ,nikogo to nie obchodziło. Nagle jak się jeden klient wysypał, to cięcia gdzie się tylko dało. Oczywiście w stylu amerykańskim po fakcie, przed nie warto było słuchać, że trzeba ludzi przeszkolić, bo marnujemy kolosalną kasę itd.

[mr_hammerer]

pole typu char(1) w którym są tylko 2 stany

@masaj: wrzuciłeś coś czego nie objaśniłeś. Jak rozwiązałbyś to lepiej? number(1)? Doprecyzuj proszę, bo nie łapie twojego "łajania tłuków" ( ͡° ͜ʖ ͡°). Może przytocz jakie mieli argumenty.
Jeżeli ktoś przez aplikację waliduje wpisywane wartości (np sex: m/f) to po co się rozdrabniać na number i tłumaczyć co jest jedynką a co zerem? Odnosisz to tylko do typów

[masaj]

@mr_hammerer: T - Tak, N - Nie.
Ja w takiej sytuacji używam typu bit. ORM mapuje mi to na boolean i moim skromnym zdanie tak to powinno wyglądać. Jeśli masz sytuacja dotycząca płci, to widzę sens używania pojedynczych literek. Ale przy „tak/nie”?