Czy to źle zaprojektować użycie tablic w bazie danych?

Question

Więc tworzę bazę danych dla osobistego projektu, aby uzyskać więcej niż tylko moje stopy z PostgreSQL i niektórych języków i aplikacji, które mogą korzystać z bazy danych PostgreSQL.

Doszedłem do wniosku, że używanie tablicy niekoniecznie jest zgodne (tablice nie są atomowe, prawda?) Z 1NF. Moje pytanie brzmi: czy w ten sposób brakuje skuteczności lub bezpieczeństwa danych? Czy powinienem się wcześnie nauczyć, aby nie używać tablic?

Answer 1

Krótka odpowiedź do tytułu: Nie

Nieco dłużej odpowiedzieć:

Trzeba nauczyć się korzystać z tablic w razie potrzeby. Tablice nie są złymi projektami, są one atomowe jak zmienne pole znaków (tablica znaków, nie?) I istnieją, aby ułatwić nam życie, a nasze bazy danych były szybsze i lżejsze. Istnieją problemy rozważa przenoszenia (większość systemów baz danych nie obsługują macierze, albo zrobić to w inny sposób niż PostgreSQL)

Przykład:

masz bloga z postami i tagi, a każda wiadomość może mieć 0 lub więcej tagów. Pierwszą rzeczą, która przychodzi na myśl, jest utworzenie innej tabeli z dwiema kolumnami: postid i tagid i przypisanie znaczników do tej tabeli.

Jeśli potrzebujemy przeszukać posty z tagidem, to dodatkowa tabela jest konieczna (oczywiście z odpowiednimi indeksami).

Ale jeśli chcemy, aby informacje o znacznikach były wyświetlane jako dodatkowe informacje o poście, możemy z łatwością dodać kolumnę z liczbą całkowitą w tabeli wpisów i wyciągnąć z niej informacje. Można to jeszcze zrobić za pomocą dodatkowej tabeli, ale użycie tablicy zmniejsza rozmiar bazy danych (nie potrzeba dodatkowych tabel ani dodatkowych wierszy) i upraszcza zapytanie, pozwalając nam wykonywać nasze wybrane zapytania przy łączeniu z jednym mniejszym stołem i wydaje się łatwiejsze do zrozumienia przez ludzkie oko (ostatnia część jest w oku patrzącego, ale myślę, że mówię tutaj dla większości). Jeśli nasze tagi są wstępnie załadowane, nie jest wymagane nawet jedno sprzężenie.

Przykład może być słaby, ale jest to pierwsze, co przyszło mu do głowy.

Wnioski:

Tablice nie są konieczne. Mogą być szkodliwe, jeśli użyjesz ich niewłaściwie. Możesz żyć bez nich i mieć świetną, szybką i zoptymalizowaną bazę danych. Jeśli rozważasz możliwość przenoszenia (np. Przepisywanie systemu do pracy z innymi bazami danych), nie możesz używać tablic.

Jeśli jesteś pewien, że będziesz trzymać się PostgreSzu, możesz bezpiecznie korzystać z tablic tam, gdzie uznasz to za stosowne. Istnieją one z jakiegoś powodu i nie są ani złym projektem, ani niezgodnym z przepisami. Korzystając z nich we właściwych miejscach, mogą one pomóc w niewielkim stopniu dzięki prostocie struktur bazy danych i kodu, a także optymalizacji miejsca i prędkości. To wszystko.

Answer 2

To, czy tablica jest atomowa zależy od tego, co cię interesuje. Jeśli na ogół chcesz całej tablicy, to jest ona atomowa. Jeśli jesteś bardziej zainteresowany poszczególnymi elementami, to jest on używany jako struktura. Pole tekstowe to w zasadzie lista znaków. Jednak zazwyczaj interesuje nas cały ciąg.

Teraz - z praktycznego punktu widzenia wiele frameworków i ORMów nie rozpakowuje automatycznie typów tablic PostgreSQL. Ponadto, jeśli chcesz przenieść bazę danych do e.sol. MySQL wtedy będziesz

Podobnie ograniczenia z kluczem obcym nie mogą być dodane do tablicy (chyba że jest w 9.3 - nie wydaje się być).

Answer 3

Krótka odpowiedź: Tak, to zły projekt. Używanie tablic gwarantuje, że Twój projekt nie jest 1NF, ponieważ aby być 1NF, nie powinno być żadnych powtarzalnych wartości. Właściwy projekt jest jednoznaczny: przygotuj kolejną tabelę dla wartości tablicy i dołącz, kiedy ich potrzebujesz.

Tablice są specjalną cechą PostgreSQL. Nie ma w tym nic standardowego. Być może nadal jest odpowiednim narzędziem do pracy w pewnych ograniczonych okolicznościach, ale nadal starałbym się ich uniknąć. Są one cechą ostatniej instancji i będą cię wiązać z Postgresem. Możesz o to nie dbać lub nie, ale są (IMO) o wiele lepsze powody, by być żonaty z Postgresem niż z tablicami.

Największym problemem z tablicami jest to, że są kulami. Znasz je już i chcesz z nich korzystać, ponieważ są ci znane. Nie działają jednak tak, jak się spodziewasz, a pozwolą ci tylko odroczyć prawdziwe zrozumienie SQL i relacyjnych baz danych. Lepiej poczekaj, aż będziesz zmuszony ich użyć, niż ich się nauczyć i szukać okazji, by na nich polegać.