Wpis z mikrobloga

to będę pisał tyle #sql.


@phoe: Przecież tam nie ma jakoś dużo tego SQLa, jakieś same proste SELECTy i INSERTy, poza tym brakuje foreign keys i nie ma migracji, jak Ty chcesz to utrzymywać?

CHECK (login ~ '^[a-zA-Z0-9]{3,}$'),
CHECK (email ~ '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+[.][A-Za-z]+$'));
Z robieniem tego typu walidacji na bazie to się jeszcze nie spotkałem i nie wydaję mi się to dobrym pomysłem, nie da się napisać do tego testu jednostkowego,
@plan_9: migracji jeszcze nie ma, bo serwis jest w fazie powstawania. Kod do zarządzania migracjami będę pisał pod koniec, kiedy to coś już będzie stało na nogach.

W których miejscach brakuje FK?

Nie widzę problemu w testowaniu regexów jednostkowo - albo testuję te regexy lokalnie w kodzie aplikacyjnym (przez co niestety duplikuję kod), albo łączę się z postgresem i wołam SELECT 'asdfg' ~ '^[a-zA-Z0-9]{3,}$'.
@phoe: Przy developmencie migracje też są przydatne, zwłaszcza jeśli pracuje nad tym więcej osób ale nawet jeśli sam to robisz to i tak jest wygodniej jeśli masz migracje.

A ok jest są tam REFERENCES, patrzyłem tylko po FOREIGN KEY
Czyli na poziomie aplikacji masz zrobione jeszcze raz te walidacje i tam napisane testy? To w sumie po co jeszcze ta walidacja na bazie?

albo łączę się z postgresem i wołam
@plan_9: przy developmencie chcę mieć w tabeli tylko dane przykładowe i wrzucać je do bazy przy każdej reinstalacji. Póki co, będę pracować nad tym sam.

Walidacja w bazie jest po to, żeby uniknąć wejścia niepoprawnych danych do bazy. Wychodzę z założenia, że aplikacja aplikacją, ale baza danych ma trzymać fason sama z siebie i chronić się przed próbą wsadzenia do niej niepoprawnych danych. Jeśli baza wpuściła do siebie niepoprawne dane, to
@phoe: testy regresyjne możesz nawet łatwiej robić mając całą logikę w aplikacji.
Jest też sporo sytuacji kiedy jakiś zbiór danych jest niepoprawny - żeby to sprawdzić zamierzasz robić skomplikowane procedury i triggery w bazie czy uznasz że to już będziesz sprawdzał w aplikacji?
@asciiterror: na chwilę obecną wychodzę z założenia, że baza danych powinna bronić się sama.

Jeśli okaże się to nie do przejścia, a triggery będą zbyt skomplikowane - trudno, przejdę wtedy na walidację w aplikacji.