Napisał Bora w czwartek, 23 lutego 2006 o 17:03

Zawsze zamiast pakowac w jedną tabelke (co czasami jest słuszne wystarczy tylko enum do rozróżenia) możesz zrobić jakiś własny sprytny data provider i potem tylko pobierać dane z róźnych tabel i wstrzykiwac w ten schemat.

Napisał radziel w czwartek, 23 lutego 2006 o 18:27

Faktem jest że najprościej byłoby upchać wszystko do jednej tabeli, i potem zgodnie z VFS odwzorowywać do obiektów php. Koncepcja dla mnie interesująca jednak *dobrych* artykułów w sieci jak na lekarstwo...

Napisał Zyx w czwartek, 23 lutego 2006 o 18:40

Tja, z tą jedną tabelą to może przesadziłem, bo np. taki artykuł i profil użytkownika ciężko w jednej tabeli upchnąć :). Niemniej łączenie podobnych danych, np. tych recenzji i newsów, jak podałem w przykładzie Webcity, jest jak najbardziej wskazane. Może za jakiś czas coś o tym napiszę.

Napisał Denver w czwartek, 23 lutego 2006 o 18:56

Szczerze mówiąc, jestem w trakcie pisania kodu niezbyt dużego wortalu miejskiego, w którym z założenia pojawią się: newsy, artykuły, opisy knajp, rozkład PKP/PKS, atrakcje regionalne itp. Zacząłem się właśnie zastanawiać, czy nie lepiej byłoby mi upchać wszystko w jedną tabelę... O ile newsy i artykuły mają prawie że identyczne pola w MySQL (z niewielkimi różnicami), to reszta działów może być już trochę bardziej kłopotliwa. Ciekaw jestem jak byście to rozwiązali?

PS. Zyx - skoro to dwudniowy projekt blitzkrieg, to czemu marnujesz czas na pisanie newsów :))) Później będziesz sobie pluł w brodę, że nie zdążyłeś. No ale wierzę w dobrą organizację czasu, co w naszej fusze jest dość istotną kwestią.

Napisał splatch w czwartek, 23 lutego 2006 o 20:20

W P of EAA Fowler pokazuje kilka rozwiązań i myślę, że Ty wpadłeś na to samo - Wzorzec SingleTableInheritance. Wszystko zależy od tego czy zachodzą związki. W twoim wypadku związki nie zachodziły bądź się pokrywały i dlatego całość tak szybko poszła. :)

Co do konsolidacji systemów - myślę, że to kwestia udostępnienia przez hurtowników odpowiedniego API opartego np na SOAPie albo RESTie. Sprzedawcy mogliby wtedy automatycznie obsługiwać zamówienia. Chociaż z tego co mi wiadomo, większość sklepów produkty takie jak monitory etc. wszystko co duże ściąga jeśli jest taka potrzeba (czyt. składają zestaw) i nie trzyma w magazynach zbyt wielu produktów, bo to są pieniądze, które tracą wartość. :)

Napisał shw w piątek, 24 lutego 2006 o 00:55

Co do upychania wszystkiego w jedno miejsce - pomijajac fakt, ze jest to wysoce nieczytelne, to z praktycznego punktu widzenia - nadmiar danych.
Tak to mam tabelke recenzje i w niej wiem, ze sa recenzje, w newsach newsy - nie potrzebuje osobnego pola na rozpoznanie tresci - a pole zajmuje - moze malo, ale zawsze pewna ilosc miejsca. Pomijajac, ze wszelkie operacje staja sie utrudnione - bo im wieksza tabela a bedzie wieksza o tyle razy, ile upchasz oddzielnych "modulow" w jedna tabele, tym mniejsza wydajnosc bazy.
Tak wiec nie przemawia do mnie pojscie na latwizne, z powodu checi zaoszczedzenia czasu wcale nie tak wielka oszczednosc - w zamian za obsluzenie 1 tabeli, mamy problem ze sprawdzaniem typow rekordow itd.. Wychodze z zalozenia, ze kod pisze sie raz - mozna na niego poswiecic 10% wiecej czasu, ale napisze sie raz, a dobrze - wszelkie okrajanie, oszczednosci w czasie wychodza potem i odbijaja sie niejednokrotnie.
No i pomijam fakt, ze takie podejscie nie jest zgodne z teoria tworzenia baz danych.

A tego wyjscia poza webmasterstwo zupelnie nie rozumiem. Raz, ze wizja jest nierealna przyjanmniej przez kolejne kilkadziesiat lat - bo widze juz te masowe zwolnienia, kiedy wszystko dziala z automatu, a dwa, ze kazdy zawsze bedzie uwazal, ze akurat jego interface jest tym wlasciwym, powstanie jeden standard by Microsoft, drugi by Linux, trzeby by Bog Wie Kto.

Napisał Zyx w piątek, 24 lutego 2006 o 07:26

Denver -> napisanie tego wpisu zajęło mi dosłownie sześć minut :). Co jakiś czas muszę sobie małe przerwy robić. O projekt się nie martw - zdążyłem :).

Shw -> a jak produkt może być jednocześnie newsem? Takie wymagania mam postawione do tego mojego projektu. Do przechowywania danych na Webcity rozpracowałem nieco bardziej złożony schemat. Jest sobie drzewko w jednej tabelce i do niego podpinamy różne zasoby: obrazki, teksty, pliki itd. - każdy typ umieszczony jest w osobnych tabelkach. Ale dzięki temu, że są przypisane do liści drzewa, można bardzo łatwo robić np. newsy albo dział download: nakazujesz systemowi wyświetlić taki a taki węzeł w tym miejscu, taki w tamtym itd. Nie wspomnę też o banalnej możliwości robienia porządków - wystarczy przenieść element do innego liścia i po kłopocie. Zatem ostateczny typ identyfikują liście, do których podpięte są elementy. Robienie dwudziestu tabel na podobne teksty dla mnie z kolei sensu nie ma. To tak, jakby robić spis ludzi i robić osobne tabele dla murzynów, dla białych, dla Chińczyków, by pola "typ" nie umieszczać :P.

Wyjście poza webmasterstwo to sytuacja czysto hipotetyczna, wcale nie chciałem roztrząsać tu kwestii związanych z wdrażaniem tego systemu, lecz skupić się na architekturze.

Napisał shw w sobotę, 25 lutego 2006 o 02:27

jezeli produkt jednoczesnie moze byc news'em, to ok.
porownanie do rasy troche nietrafione, ale przyznasz, ze biorac pod uwage, ze bedzie wieksza ilosc rekordow - pole typ staje sie naddatkiem.
"przenoszenie do innego liscia" jest sytuacja niestandardowa - tworzac news jestesmy przekonani, ze do konca news bedzie news'em a nie np. artykulem. przenoszenie tresci miedzy typami wyswietlanych informacji to sytuacja niestandardowa, wyjatkowa i nie sadze, aby byla dobrym powodem do przyjecia okreslonej strategii zapisu danych w bazie.
w twoim rozumowaniu widze ciagle podejscie do problemu tak, aby zmniejszyc czas i wzglednie przyspieszyc tworzenie danego oprogramowania - a ja szczerze powiedziawszy nie lubie takiego podejscia.
ja rozumiem, ze mozesz sobie wziasc i przekopiowac kod z czesci odpowiedzialnej za newsy do czesci odpowiedzialnej za produkty, zrobic kosmetyczne poprawki i po problemie, ale chyba nie tedy droga.
od dluzszego czasu nie pisze praktycznie w php - praca zmusza chociaz specjalnie nie czuje sie zmuszany do pracy z .NET'em, tak wiec pisze w troche bardziej zaawansowany sposob niz to jest przyjete w php. np. ostatnio pisze projekt aplikacji desktopowej, w ktorej przetwarzana jest, spora ilosc informacji. baza danych nie jest moze przesadnie wielka, ale ma te swoje "kilka" tabel. czesc z nich moznaby polaczyc w jedno, ale powstaje problem - raz, ze typow danych, dwa, ze czytelnosci kodu.
jak wiec pogodzic ze soba typy danych i czytelnosc kodu z szybkim tworzeniem aplikacji? przez odpowiednio napisany framework, ktory zajmuje sie zapisywaniem, usuwaniem, pobieraniem danych w wiekszosci standardowych operacji - metody sa dziedziczone po klasie bazowej. dane z obiektow sa przetwarzane w odpowiednie zapytanie sql, a ja operuje jedynie na obiektach.
naddatek pracy to zwyczajne stworzenie obiektu - raz - a uzywany jest wielokrotnie.
tak wiec mysle, ze wlasnie takie cos powoduje, ze i wilk syty i owca cala :)

Napisał MySZ w sobotę, 25 lutego 2006 o 10:08

No właśnie do podobnego wniosku (konsolidacja) doszliśmy z kumplem, gdy zaczęliśmy przepisywać na nowo nasz CMS. Wcześniej (stara wersja jest w ogóle źle napisana, ale to szczegół) newsy miały osobną tabelę, to samo strony, komentarze etc. Teraz wszystkie rodzaje wpisów korzystają z jednej, i ma tylko te pola, które uznaliśmy że będą najczęściej się powtarzać. Do tego dochodzi druga tabela, która nazwana jest 'meta', i gdzie są przechowywane dodatkowe pola/właściwości wpisów (jak na przykład czy wpis umożliwia zostawianie komentarzy etc).
Tego typu rozwiązanie daje niesamowitą elastyczność.