Inicjalizacja bazy danych

W jaki sposób generujecie początkowy stan bazy danych, to znaczy: tworzenie wszystkich użytkowników, ról, schematów, tabel i tak dalej?
Chodzi mi o narzędzia generujące całościowe skrypty na podstawie diagramów, pozwalające postawić bazę od zera, umożliwiające wyklikać dużo rzeczy - tabele co najmniej (jakieś unikalności kolumn itp.), ale też umożliwiające dopisane własnych skryptów, gdy brak obsługi w narzędziu.
Czy z palca piszecie? Interesują mnie najbardziej narzędzia dla Postgresa, ale dla innych baz też chętnie posłucham.

Flyway

Spectra napisał(a):

Flyway

No tak chyba średnio. W sensie - to fajne narzędzie, ale raczej do zarządzania wersjami/do migracji. A OP pyta o tworzenie pustej bazy - jak np. instalujesz jakiegoś ERP i on wymaga bazy do działania (takiej stawianej lokalnie, nie do działania w chmurze) - więc instalator Twojej apki, oprócz instalowania samego programu, jeszcze musi zainstalować bazę (w sensie - jako silnik), potem ją skonfigurować - stworzyć dostępy, założyć bazy, stworzyć tabele, wypełnić może jakimiś danymi startowymi/domyślnymi itp. Także raczej to nie jest odpowiedź jaka się przyda.

U mnie zwykle i tak jest code first. Ale do Postgresa polecany jest też pgModeler, ludzie sobie to chwalą.

więc instalator Twojej apki, oprócz instalowania samego programu, jeszcze musi zainstalować bazę (w sensie - jako silnik), potem ją skonfigurować - stworzyć dostępy, założyć bazy, stworzyć tabele, wypełnić może jakimiś danymi startowymi/domyślnymi itp. Także raczej to nie jest odpowiedź jaka się przyda.

Nie rozumiem problemu - jeśli masz na myśli klasyczny instalator desktop, albo jakiś webowy kreator, to czy nie wystarczy że dostanie sql, który wykona?

@cyclicgraph: trzeba wybrać jakaś filozofię i się jej trzymać!
np. sprawdzasz numer modelu w bazie danych i kolejno aktualizujesz, 0,1,2,3...aktualny
żadnego klikania tylko w Twoim programie masz dodatkową szczyptę logiki która pilnuje aby kod był spójny z modelem SQL.

Generalnie na przyszłość to proponuję podać dokładny case jaki masz, powiedzieć jak do niego podchodziłeś do tej pory i wtedy poprosić o sugestie na podstawie doświadczenia, prędzej dostaniesz satysfakcjonującą Cię odpowiedź (obecne pytanie jest bardzo ogólne).

Thought for 9s

Najczęściej nie warto generować jednego wielkiego skryptu i później ręcznie go poprawiać. Dobrze działa rozdzielenie:

model/diagram jako opis pożądanego schematu,
wygenerowany DDL do postawienia nowej bazy,
wersjonowane migracje do rozwijania istniejących środowisk,
osobny bootstrap instancji: role, użytkownicy, baza, rozszerzenia i uprawnienia.
Najlepsze dopasowanie do Twojego opisu: pgModeler

Dla PostgreSQL zacząłbym od pgModelera. Jest nastawiony konkretnie na Postgresa, a nie na „wspólny najmniejszy mianownik SQL”.

W GUI można modelować między innymi:

schematy, tabele i kolumny,
PRIMARY KEY, UNIQUE, CHECK, klucze obce,
indeksy, sekwencje i partycjonowanie,
widoki, funkcje, procedury i triggery,
typy, domeny i rozszerzenia,
polityki RLS,
role, członkostwo ról i uprawnienia,
tablespace’y.

Model może zostać wyeksportowany jako pełny skrypt SQL albo zastosowany do serwera. Narzędzie potrafi również porównać model z istniejącą bazą i wygenerować SQL synchronizujący różnice.

Bardzo istotna w Twoim przypadku jest możliwość dodawania własnego SQL:

do obiektu można dopisać SQL wykonywany przed lub po jego utworzeniu,
można tworzyć niezależne „Generic SQL objects”, których treść jest dołączana do końcowego skryptu.

To pozwala obsłużyć konstrukcje, których GUI nie zna, oraz np. dane słownikowe, specjalne GRANT, konfigurację rozszerzeń czy własne bloki DO $$ ... $$.

Jedno zastrzeżenie: Generic SQL objects są uwzględniane przy eksporcie całego modelu, ale dokumentacja zaznacza, że nie uczestniczą normalnie w mechanizmie diff. Trzeba więc uważać, żeby taki fragment nie zniknął z procesu późniejszych migracji.

Mój wybór, gdy wymagania brzmią „diagram + dużo klikania + pełny PostgreSQL + własny SQL”: pgModeler.