Temat: Projekt bazy

Projektuje mały cms - tak dla siebie i jestem na etapie trzymania treści w bazie.

Większość robi tak że daje id,tytuł,..., dostepnosc, kategoria itd., ja się zastanawiam czy nie dać tak aby w głównej tabeli artykuły dać tylko podstawowe kolumny jak id, tytuł, treść i stworzyć analogicznie kolejne tabele z kolumnami id,kategoria.

Proszę o odpowiedź co będzie wydajniejsze i bezpieczniejsze szczególnie jeżeli chodzi o wyszukiwanie informacji.

Temat: Projekt bazy

jeśli dobrze poindeksujesz tabele to wydajnosc spadnie nieznacznie jesli je rozproszysz. ja proponuje słownikowanie: jedna tabela id, artykul, druga id, uprawnienia, tzrecia id, dostepnosc.. itd

majac tabelki/tabelke ze slownikiem mozesz potem wyszukiwanie oprzec na jeden tabelce w ktrej rekordy beda wygladaly mniej wiecej tak:

1;2;1;3;4;13

Temat: Projekt bazy

Piotr B.:
Większość robi tak że daje id,tytuł,..., dostepnosc, kategoria itd.

no i zle robia, informacje w bazie danych nie powinny sie powtarzac, mowi o tym cala teoria normalizacji schematow bazodanowych. slownikowanie z kolei to bardzo dobra metoda, dzieki ktorej, bez glebszej znajomosci postaci normalncyh mozna zaprojektowac rozsadna baze :)

Temat: Projekt bazy

Dzięki za odpowiedzi. Czyli jednym słowem Każdą opcję takiego artykułu w osobną tabele.

PS. Macie linki do polskich stron o normalizacji??

Temat: Projekt bazy

Z jednej strony racja - normalizacja ładnie wygląda w teorii.
Z drugiej strony query na znormalizowanej bazie zmieniają się w gąszcz joinów, w którym może być ciężko się połapać, i które mocno obciążają maszynę.

Temat: Projekt bazy

Piotr B.:
PS. Macie linki do polskich stron o normalizacji??

Mamy, trochę ich jest:
http://www.google.pl/search?hl=pl&q=bazy+danych+postac...

Pozdrawiam

Temat: Projekt bazy

Jakub L.:
Z jednej strony racja - normalizacja ładnie wygląda w teorii.
Z drugiej strony query na znormalizowanej bazie zmieniają się w gąszcz joinów, w którym może być ciężko się połapać, i które mocno obciążają maszynę.

No właśnie dlatego się pytałem, bo tak naprawdę wtedy prawie każde zapytanie do bazy jest z JOINem. Fakt faktem aplikacja będzie miała "keszowanie" wyników i w dodatku będzie to na serwerze dedykowanym.

Z drugiej strony łatwiej się dodaje i uaktualnia.

Temat: Projekt bazy

ale na tym polega cala zabawa w bazy danych, ze zawsze opiera sie na kwerendach z JOINami. w koncu to sa relacyjne bazy danych.

nalezy sie wystrzegac traktowania db jako "worka na rekordy". przyklad co moze sie popsuc przy pierwszym proponowanym rozwiazaniu :

1. user A wyswietla formatke dodawania artykulu do kategorii "biznes"
2. user B zmienia nazwe kategorii "biznes" na "e-commerce"
3. user A wpisuje artykul na formatce i kllika submit.
4. mamy teraz artykuly z kategorii e-commerce" i jeden artykul z kategorii "biznes"
(5) ewentualnie jeszcze sie moze na koniec zdazyc tak, ze probujac teraz zmienic "biznes" na "e-commerce" dostaniemy blad ze taka kategoria juz istnieje

dobre rozdzielenie zaleznosci pomiedzy danymi pozwala ograniczyc liczbe takich nieprzewidzianych wpadek.

Temat: Projekt bazy

Jakub B.:
ale na tym polega cala zabawa w bazy danych, ze zawsze opiera sie
na kwerendach z JOINami. w koncu to sa relacyjne bazy danych.

Zapytaniach.
Tylko problem jest taki, że na uczelni to baza ma być znormalizowana żeby dostać piątkę, a na produkcji to ma nie wysypywać się i działać pod bliżej nieokreślonym obciążeniem.
Dyski są tanie, więc czasem robi się standardowy trade-off - czas (i mniejszy load) za pamięć i zostawia bazę nieznormalizowaną.

nalezy sie wystrzegac traktowania db jako "worka na rekordy".

Bo? Worek na rekordy to fajna rzecz. I baza ma fajne mechanizmy do trzymania wora rekordów - indeksy, samouczenie się, często korzystanie z fizycznej struktury dysku, optymalizacja często wykonywanych operacji i tak dalej.
Traktowanie bazy jako flat file ma te zalety, że nie trzeba się martwić fizyczną organizacją danych - baza zrobi to za ciebie.
Jest środkiem, nie celem.

przyklad co moze sie popsuc przy pierwszym proponowanym rozwiazaniu :

1. user A wyswietla formatke dodawania artykulu do kategorii "biznes"
2. user B zmienia nazwe kategorii "biznes" na "e-commerce"
3. user A wpisuje artykul na formatce i kllika submit.
4. mamy teraz artykuly z kategorii e-commerce" i jeden artykul z kategorii "biznes"
(5) ewentualnie jeszcze sie moze na koniec zdazyc tak, ze probujac
teraz zmienic "biznes" na "e-commerce" dostaniemy blad ze taka kategoria juz istnieje

Wydumane. Często coś takiego się zdarza?

dobre rozdzielenie zaleznosci pomiedzy danymi pozwala ograniczyc liczbe takich nieprzewidzianych wpadek.

Ale nie jest Świętym Graalem ani silver bullet, obawiam się.

Temat: Projekt bazy

Jakub B.:
1. user A wyswietla formatke dodawania artykulu do kategorii "biznes"
2. user B zmienia nazwe kategorii "biznes" na "e-commerce"
3. user A wpisuje artykul na formatce i kllika submit.
4. mamy teraz artykuly z kategorii e-commerce" i jeden artykul z kategorii "biznes"
(5) ewentualnie jeszcze sie moze na koniec zdazyc tak, ze probujac teraz zmienic "biznes" na "e-commerce" dostaniemy blad ze taka kategoria juz istnieje

Przykłady można mnożyć i mnożyć. Połowa sukcesu zależy od tego, jak będzie baza zaprojektowana, jakie tabele, widoki, więzy spójności, indeksy itd.
Druga połowa to sama aplikacja. W podanym przez Ciebie przykładzie można się łatwo zabezpieczyć przed taką sytuacją właśnie na poziomie aplikacji.

Temat: Projekt bazy

Jakub L.:
Tylko problem jest taki, że na uczelni to baza ma być znormalizowana żeby dostać piątkę, a na produkcji to ma nie wysypywać się i działać pod bliżej nieokreślonym obciążeniem.

na produkcji zwykle wysypuje sie wlasnie z powodu braku sensowanej organizacji danych. pracowalem przez pol roku przy rozbudowanym systemem finansowym bezposrednio przy jego bazach i z doswiadczenia wiem jak "dziala" w praktyce aplikacja, ktorej baza nie jest sensownie znormalizowana. Nieznormalizowana baza produkcyjna to jeden wielki chaotyczny wor z danymi, ktorych czesc niekiedy okazuje sie sprzeczna sama ze soba. Jesli zmienia sie np adres klienta, to trzeba upilnowac, aby zupdate'owac go w 10ciu tabelach, co jest jeszcze sprawa prosta, jesli ograniczyc sie tylko do jednego hermetycznego systemu. A tu nagle dochodza jeszcze inne systemy, przypiete do jego interfejsu uslugowego. Na poziomie calosci zdarzaja sie naprawde ladne kwiatki. Widzialem tez systemy ktorych schematy byly zbudowane "po bozemu" i jakosc tych systemow byla ewidentnie wysoka - zespoly ktore sie nim zajmowaly nie mialy za duzo roboty z utrzymaniem tegoz.

nalezy sie wystrzegac traktowania db jako "worka na rekordy".

Bo? Worek na rekordy to fajna rzecz.

pewnie, do ksiegi gosci na przyklad.
generalnie, nie da sie napisac aplikacji w 100% bezblednej, zawsze zawinie sie kilka procedur, ktore beda co jakis czas wrzucac tu i owdzie bzdury. i dlatego lepiej zabezpieczyc sie juz na poziomie bazy danych, aby - nie tylko niespojnosci nie rozpropagowaly sie po reszcie bazy - ale takze, aby wewnetrzne mechanizmy (constraint'sy, triggery) wylapaly wadliwy mechanizm zawczasu.

I baza ma fajne mechanizmy do trzymania wora rekordów - indeksy, samouczenie się, często korzystanie z fizycznej struktury dysku, optymalizacja często wykonywanych operacji i tak dalej.

To nie rozumiem dlaczego nie wykorzystac indeksow i samouczenia sie software'u, wspierajac go informacjami o zalenosciach pomiedzy poszczegolnymi danymi.

Optymalizacja takiego DB2 czy Oracla do wydajnej pracy z rozbudowanymi JOINami spokojnie pozwala pracowac systemom opartym o porzadnie znormalizowane schematy baz. Cache'owanie wynikow na poziomie podzapytan, kompilacja fragmentow SQLa do kodu maszynowego, "prepared statements", "batch queries"...

Traktowanie bazy jako flat file ma te zalety, że nie trzeba się martwić fizyczną organizacją danych - baza zrobi to za ciebie.

Dokladnie to samo zrobi za mnie, jesli bede uzywal bazy znormalizowanej.

Wydumane. Często coś takiego się zdarza?

Wydumane - ha! wlasnie o to chodzi aby za wczasu wydumac wszystkie mozliwe konflikty i problemy, aby o 5:00 w nocy nie okazalo sie ze system kwiczy z powodu jakiejs wydumanej pierdolki, bo jakis amerykanin zjadlszy sniadanie kliknal cos bez sensu i wykrzaczyl aplikacje. Zrywaj teraz developera z lozka, bo od 8:00 wszystko musi znowu dzialac :)

Ten przyklad oczywiscie jest na kolanie sklecony. Faktury czy paragony z pozycjami na 0zł to typowy efekt wyprodukowany przez zle przemyslany system. Pozycje bedace NULLami materializuja sie w 0zl na frontendzie i - poniewaz na poziomie aplikacji nikt nie wpadl na taki usecase - ida do wydruku. Jakis czas temu byl w gazecie opis, jak to jakis urzad scigal czlowieka o zaplate 0zl.

dobre rozdzielenie zaleznosci pomiedzy danymi pozwala ograniczyc liczbe takich nieprzewidzianych wpadek.

Ale nie jest Świętym Graalem ani silver bullet, obawiam się.

Naprawde nie rozumiem tego oporu przed zadaniem sobie minimalnego trudu przemyslenia organizacji danych - nikt nie wymaga standardow na poziomie 5NF, wystarczy 3NF, a nawet samo slownikowanie.

Poza tym jesli potrzebny jest system typu "high-avaiability" zawsze mozna wesprzec sie hurtownia danych, ktora nie jest znormalizowana, ale jej ogranizacja jest odpowiednio przemyslana tak, aby zmaksymalizowac wydajnosc wstawiania i wyszkukiwania informacji.

Ja nie twierdze ze normalizacja do Swiety Graal, uwazam ze musi byc zachowana forma przemyslanej organizacji danych, a flat-file z pewnoscia do takich nie nalezy i predzej czy pozniej sie zemsci, jesli mamy do czynienia z powazna, rozbudowana aplikacja.Jakub Błaszczyk edytował(a) ten post dnia 05.08.07 o godzinie 19:27

Temat: Projekt bazy

Jakub dzięki za taki wywód. I skłonie się ku twojemu zdaniu. Choćby z tak prozaicznego powodu, że bazy mogą być naprawdę dużych rozmiarów jak ludzie zaczną wklejać jakieś pierdoły. Nie chcę dopuścić do takiej sytuacji, aby pojawiały się rekordy w których część kolumn po prostu jest równa NULL albo co gorsza 0. Tak podzielę sobie to na kilka tabel i jak danej opcji nie będzie to po prostu nie będzie i tyle.

Temat: Projekt bazy

Jakub B.:

Jakub L.:
Tylko problem jest taki, że na uczelni to baza ma być znormalizowana żeby dostać piątkę, a na produkcji to ma nie wysypywać się i działać pod bliżej nieokreślonym obciążeniem.

na produkcji zwykle wysypuje sie wlasnie z powodu braku sensowanej organizacji danych. pracowalem przez pol roku przy rozbudowanym systemem finansowym bezposrednio przy jego bazach i z doswiadczenia wiem jak "dziala" w praktyce aplikacja, ktorej baza
nie jest sensownie znormalizowana. Nieznormalizowana baza

No to coś takiego: w Polsce jest blisko 100 000 miejscowości.
Mamy hurtownię, w której są adresy, zamieszkania, zameldowania, pracy pierwszej, drugiej, trzeciej i tak dalej.
I teraz pytanie - czy zrobić słownik miejscowości i referować do niego, czy po prostu walnąć varchar(ileś) z nazwą miejscowości?
I jak wybierzesz normalizację - jak załatwisz wybór ze słownika? Lista 100k miejscowości to nie w kij dmuchał :).

Normalizacja do pewnego momentu pomaga, potem tylko zaciemnia obraz.
Jeżeli denormalizujemy, powinniśmy dokładnie znać zależności pomiędzy danymi.
Dodatkowo - widziałem w strukturze takiej jednej bazy, jak życie wymusiło normalizację do koniecznego poziomu, ale ani kroku dalej, bo nie było potrzebne.

nalezy sie wystrzegac traktowania db jako "worka na rekordy".

Bo? Worek na rekordy to fajna rzecz.

pewnie, do ksiegi gosci na przyklad.
generalnie, nie da sie napisac aplikacji w 100% bezblednej, zawsze zawinie sie kilka procedur, ktore beda co jakis czas wrzucac tu i > owdzie bzdury. i dlatego lepiej zabezpieczyc sie juz na poziomie

Generalnie to takie procedury mają za zadanie wyłapać testy.

bazy danych, aby - nie tylko niespojnosci nie rozpropagowaly sie po reszcie bazy - ale takze, aby wewnetrzne mechanizmy

Możliwość rozpropagowania się takiej niespójności to błąd projektanta bazy. Rezygnacja z normalizacji takim błędem jeszcze nie jest.

(constraint'sy, triggery) wylapaly wadliwy mechanizm zawczasu.

Constrainty, tak samo jak triggery.

Optymalizacja takiego DB2 czy Oracla do wydajnej pracy z rozbudowanymi JOINami spokojnie pozwala pracowac systemom opartym
o porzadnie znormalizowane schematy baz. Cache'owanie wynikow na poziomie podzapytan, kompilacja fragmentow SQLa do kodu maszynowego, "prepared statements", "batch queries"...

Masz do wyboru - zrobić akademicką bazę a potem tuningować silnik, albo olać część teorii, w której dokładnie wiesz co robisz, i mieć podobne efekty wydajnościowe.
Wybierz, co robisz jak termin goni :>.

Wydumane. Często coś takiego się zdarza?

Wydumane - ha! wlasnie o to chodzi aby za wczasu wydumac wszystkie mozliwe konflikty i problemy, aby o 5:00 w nocy nie okazalo sie ze system kwiczy z powodu jakiejs wydumanej pierdolki, bo jakis amerykanin zjadlszy sniadanie kliknal cos bez sensu i wykrzaczyl aplikacje. Zrywaj teraz developera z lozka, bo od 8:00 wszystko musi znowu dzialac :)

Od tego są testy. Nie wiem jak w @vantage, ale w moim dziale testerów było prawie tyle samo co developerów, a potem jeszcze były ze trzy stopnie testów.
Jeżeli firma puszcza do klienta niedotestowany soft, to jest krzaczasta i tyle.
A rano w Ameryce to chyba u nas tak pod wieczór jest.

Ten przyklad oczywiscie jest na kolanie sklecony. Faktury czy paragony z pozycjami na 0zł to typowy efekt wyprodukowany przez zle przemyslany system. Pozycje bedace NULLami materializuja sie w 0zl na frontendzie i - poniewaz na poziomie aplikacji nikt nie wpadl na taki usecase - ida do wydruku. Jakis czas temu byl w gazecie opis, jak to jakis urzad scigal czlowieka o zaplate 0zl.

A masz 100% pewności, że te pozycje to efekt braku normalizacji a nie jakiegoś błędu popełnionego w zupełnie czymś innym?

dobre rozdzielenie zaleznosci pomiedzy danymi pozwala ograniczyc liczbe takich nieprzewidzianych wpadek.

Ale nie jest Świętym Graalem ani silver bullet, obawiam się.

Naprawde nie rozumiem tego oporu przed zadaniem sobie minimalnego
trudu przemyslenia organizacji danych - nikt nie wymaga standardow
na poziomie 5NF, wystarczy 3NF, a nawet samo slownikowanie.

Nadinterpretujesz, nigdzie nie pisałem, żeby olać normalizację i robić jak leci, tylko aby w niektórych przypadkach rozważyć jednak denormalizację.
3NF w niektórych miejscach może być przegięciem.

Ja nie twierdze ze normalizacja do Swiety Graal, uwazam ze musi byc zachowana forma przemyslanej organizacji danych, a flat-file

Forma przemyślanej organizacji danych nie oznacza automatycznie 3NF.

Temat: Projekt bazy

Jakubie L. poprzyj proszę swoje tezy o jakieś produkcyjne przykłady wzięte z życia. Jeśli mogę prosić oczywiście.
Osobiście uważam, że obydwaj macie rację - normalizacja tak owszem jak najbardziej ale nie zawsze jest potrzebna. Domyślam się że kolega Błaszczyk ma doświadczenie z banku i rozumiem bardzo dobrze jego podejście - słownikowanie w takich systemach to wymóg bezpieczeństwa bazy i jest nie do obalenia. Sam pracuję na ogromnej ilości rekordów i dobrze znam problem (faktury i 100k miejscowosci moga sie schować).

Czasem jednak proste rozwiązania są najlepsze - tu jednak decyzja zostaje po stronie projektanta bazy i tylko on po zapoznaniu się z możliwymi problemami decyduje jakie rozwiązanie zastosuje.

Porównywanie akademickich projektów do żywych produkcyjnych systemów jest bezcelowe - nigdy w takich projektach nie zaznamy problemów, których mnóstwo znajdziemy w ogromnych systemach korporacyjnych. I warto się namęczyć przy tworzeniu kodu strony/programu czy też procedury na bazie - owocuje to porządkiem w systemie i łatwością znalezienia bug'a.

Temat: Projekt bazy

Jacek O.:
Jakubie L. poprzyj proszę swoje tezy o jakieś produkcyjne przykłady wzięte z życia. Jeśli mogę prosić oczywiście.

Finn - Rejestr Lekarski - soft do robienia rejestru lekarzy https://www.finn.pl/xml/programy/rejestr/pobierz - przykład
z brakiem normalizacji bazy adresów - funkcjonalne i biznesowe powody (okazało się, że GUS liczy sobie parę klocków za bazę miejscowości w Polsce, no i zesłownikowanie 100k miejscowości byłoby lekko bezcelowe - jak z takiego słownika wybierać - po AJAXowemu - po każdej literce select where nazwa like 'literki%' - śmierć dla serwera, czy po wpisaniu nazwy sprawdzić i się dopytywać usera?).

Wymuszenie normalizacji - poprzedni soft rejestru zrobiony przez nieinformatyka - była sytuacja praktyki prywatnej i gabinetu - praktyka może mieć więcej niż jeden gabinet, najpierw gabinet był w strukturze tabeli praktyki, później został wyjęty do osobnej, zostały artefakty.

Z resztą podsumowania pełna zgoda.

I proces jest taki, że najpierw bada i organizuje się dane, później teoretyczna normalizacja, a dopiero na końcu denormalizacja dla osiągnięcia performance'u i projekt bazy.

Temat: Projekt bazy

wiesz.. 'pare klockow' to jednak zadna cena... 'smierc dla serwera'? zalezy dla jakiego :)
wszystko to kwestia branzy/firmy/specyfiki bazy

i tak jak pisalem wczesniej - masz tez swoja racje

Temat: Projekt bazy

Dzięki za odpowiedzi na moje pytanie.

Jednak chyba trochę odbiegacie od tematu:). Ja nie tworze strony banku ani hurtowni danych. Potrzebuje dobrze zaprojektowanej STABILNEJ bazy danych do średniej wielkości cms'a. Najprawdopodobniej będzie na MySQL, ale jeżeli uda mi się załatwić to będę szczęśliwym posiadaczem MS SQL 2005 co jest o niebo lepsze.

Dlatego sie pytałem czy wszystkie opcje władować w jedną tabelę, ale wiem z doświadczenia, że znaczna część będzie albo zerem albo nullem, a w przypadku rozbicia nie będzie tej sytuacji.

Patrzałem np. na mambo - oni mają wszystkie, znaczy większość opcji w jednej i w dodatku tworzą coś a'la tablice cos|cos|cos - co dla mnie jest bez sensu. Jeżeli baza mambo jest napakowana to widać jak się muli. Ja na starcie zabezpieczyłem się dobrym serwerem, ale wiem, że jak baza będzie źle zrobiona to i tak mi to nie pomorze.

Temat: Projekt bazy

Jest kilka poziomów normalizacji baz, a ja dodatkowo uważam, że jest też poziomów kilka denormalizacji i kilka debilizacji. :)

Żeby nie odbiegać od tematu i reasumując: wybrałbym bazę wykorzystującą ID słowników dla publikowanych dokumentów. Używając indeksów przyspieszysz ją, ale najważniejsze jest, byś cashe'ował informacje w pamięci, w samej witrynie. Eliminujesz do minimum odpytywanie bazy i nawet jeśli jest nieoptymalna, to całość będzie działać szybko dla odwiedzającego witryny.

W bazach znormalizowanych zapytania wyglądają mniej przyjaźniej, ale za to rozbudowa samej bazy nie nastręcza żadnych kłopotów.

pozdr. edi

Temat: Projekt bazy

Edward W.:
Żeby nie odbiegać od tematu i reasumując: wybrałbym bazę wykorzystującą ID słowników dla publikowanych dokumentów. Używając indeksów przyspieszysz ją, ale najważniejsze jest, byś cashe'ował informacje w pamięci, w samej witrynie. Eliminujesz do minimum odpytywanie bazy i nawet jeśli jest nieoptymalna, to całość będzie działać szybko dla odwiedzającego witryny.

Najwyżej provider wyłączy serwis, jak serwis znajdzie się w pierwszej piątce najbardziej zasobożernych serwisów.
Część operacji na danych baza ma szanse zrobić szybciej niż wywleczenie wszystkich danych, przesłanie ich do skryptu i obrobienie tamże.

pozdr. edi

Temat: Projekt bazy

Jakub L.:

Najwyżej provider wyłączy serwis, jak serwis znajdzie się w pierwszej piątce najbardziej zasobożernych serwisów.
Część operacji na danych baza ma szanse zrobić szybciej niż wywleczenie wszystkich danych, przesłanie ich do skryptu i obrobienie tamże.

Jasne :) nikt normalny nie wlecze na przykład 100.000 wierszy z bazy, ani nie produkuje 2 megowego XML'a. :)

pozdr. edi