Standardy w dokumentacji aplikacji bazodanowej.

0

Witam, chce stworzyć sensowną dokumentacje do aplikacji na githuba. Mam w tym zakresie kilka pytań:

  1. Jakie są standardy w zakresie dokumentacji baz danych?
  2. Co powinna zawierać taka dokumentacja?
  3. Czy powinienem wydzielić skrypt do generowania bazy na pliki zawierające osobno np. strukturę, dane, procedury, widoki itd?

//Edit:
@AnyKtokolwiek Dokumentacja dla programisty.

2
  1. ERD + opis słowno-muzyczny, może i są jakieś normy, ale na amatorski projekt to chyba wystarczy
  2. wszystko, co potrzebne i nic więcej :) zależy, dla kogo to kwity mają być
  3. Raczej podzielić skrypty na tworzące strukturę (tabele, procedury, widoki) i wrzucające dane. Tak łatwiej deplojować różne środowiska (raczej będą się różnić od siebie danymi aniżeli strukturą danych). No i jeśli baza może być stawiana na windzie/linuchu, to skrypt tworzący katalogi itd.
1
travis.chigurh napisał(a):

Witam, chce stworzyć sensowną dokumentacje do aplikacji na githuba. Mam w tym zakresie kilka pytań:

  1. Jakie są standardy w zakresie dokumentacji baz danych?

Baza danych nie potrzebuje dokumentacji, jeśli jest poprawnie zaprojektowana i opisana.
Jest można by rzec, tworem samodokumentującym się.
Jest masa narzędzi, które na podstawie bazy danych generują super-przejrzystą dokumentację.
Np. RedGate SQLDoc

Tego się trzymam i co do zasady nie utrzymuję dokumentacji db.
Ale utrzymuję opisy w samej db; w ms sql przy pomocy sql robi się to tak:

-- Opis pola IsUser w tabeli tDfLog
EXEC sp_addextendedproperty 'MS_Description', N'id użytkownika który zmienił wartość atrybutu', N'schema', N'dbo', N'table', N'tDfLog', N'column', N'IdUser'

Wtedy jeśli ktoś poprosi o dokumentację, to bardzo proszę - klik, klik minuta i jest dokumentacja.

Tworzenie ERD?
Można, tylko zawsze i można je wygenerować; i znowu - jeśli baza danych jest poprawnie zaprojektowana :)

  1. Co powinna zawierać taka dokumentacja?

Powtarzam, poprawnie zaprojektowana baza danych nie potrzebuje dokumentacji dla programisty.
No ale jeśli nie ma zdefiniowanych FK, każde pole nazywa się inaczej w każdej tabeli mimo tego, że odzwierciedla wartość odnoszącą się do tego samego wiersza, itp. itd. to faktycznie wtedy jest problem.

Na Twoim miejscu zamiast rozmyślać nad dokumentacją, rozmyślałbym nad konwencją w bazie danych.
Przemyślałem jak nazywają się tabele, pola, zmienne, procedury itd.

Poza tym zauważyłem że niejakim "standardem" (i to fatalnym) jest nazywanie pola PK w każdej tabeli jako ID. Potem mamy to ID w innej tabeli które jest relacją do tabeli źródłowej i...
Człowiek drapie się po głowie, jak nazwać to ID? I dlaczego ono nazywa się inaczej niż w tabeli źródłowej?
Dla mnie to strzelanie sobie w kolano; ja każde ID nazywam tak, aby jego nazwa jednoznacznie mówiła co to jest za ID, a wiec z której tabeli pochodzi.
Proste i skuteczne, poza tym niektóre narzędzia potrafią automatycznie rozpoznawać pola złączeń, jeśli baza jest zaprojektowana w ten sposób - np. RedGate SQLPrompt.

A potem pozostaje tylko trzymać się tej konwencji.

Oczywiście inaczej jest kiedy baza danych powstaje jako efekt pracy ORM w modelu CodeFirst; wtedy baz danych jest bytem wtórnym, a dokumentacja dotyczy kodu, a nie bazy danych.

  1. Czy powinienem wydzielić skrypt do generowania bazy na pliki zawierające osobno np. strukturę, dane, procedury, widoki itd?

W dokumentacji?
A po co, skoro programista i tak może sobie to podejrzeć jeśli musi?

Polecam Ci wersjonować bazę danych, tak na GIT.
Ja korzystam z tego rozwiązania:
https://github.com/microsoft/mssql-scripter

Przy robieniu release odpalam taki skrypt i tyle - mam pełną historię zmian w bazie danych, ponieważ wersjonuję te pliki na GIT.

//Edit:
@AnyKtokolwiek Dokumentacja dla programisty.

1 użytkowników online, w tym zalogowanych: 0, gości: 1