Projekt bazy dla wielu użytkowników, dylemat Opcje

[siewca]

Mam pewien dylemat i mam nadzieję tutaj go rozwiać korzystając z pomocy kolegów którzy ugryźli kiedyś podobny temat

Tworzę program magazynowy dla wielu użytkowników, każdy użytkownik ma swoje konto i widzi tylko swój magazyn (o istnieniu innych nie ma pojęcia). Zakładając że każdy użytkownik w magazynie będzie miał może nawet kilka tysięcy produktów.

Rozważam jedną z trzech możliwości podczas projektowania bazy:

1. Towar wszystkich użytkowników jest w jednej tabeli, ale każdy towar ma przypisane id użytkownika po którym będzie rozpoznawany właściciel towaru (chyba najmniej wydajna opcja, tak mi się wydaje, bo przecież przy wielu użytkownikach tabela byłą by ogromna).
2. Zakładając konto użytkownikowi tworzona jest osobna tebela dla jego magazynu, jednak w obrębie tej samej bazy (wiadomo nie będzie trzeba robić tego ręcznie, wymaga minimalnej administracji)
3. Po rejestracji użytkownika, w ciągu 24 godzin administrator instaluje kopię programu na nowej bazie danych, tak więc każdy user ma swoją bazę. Niby najbardziej wydajna opcja (tak mi się zdaje) jednak przy wielu użytkownikach aktualizacja programu o nowe funkcje była by męczarnią.

Ogólnie wygodny w budowie i w późniejszym zarządzaniu był by pierwszy sposób, ale czy skrypty wyszukiwania i operacje na rekordach nie będą się mulić gdy w bazie będą tysiące produktów?

Zapraszam do dyskusji, wierzę że te informacje przydadzą się nie tylko mi.

Pozdrawiam, i sorry jeśli gdzieś jest już podobny wątek. Przejrzałem jednak ciężko ogarnąć cały dział. Furum jest ogromne

[ayeo]

Witam!

Użytkownicy systemu to osobna tabela, magazyny to osobna tabela (tutaj kwestia czy mogę mieć jeden tylko magazyn czy kilka), produkt to osobna tabela, przypisanie produktu do magazynu wraz z datą i stanem magazynowym to osobna tabela....

Dalej analogicznie

Pozdrawiam!

[Mchl]

Albo 1, albo 3 (jeżeli zależy Ci na silnej izolacji użytkowników). O 2. nawet nie myśl.
[edit]

Aha, akurat 1. będzie najbardziej wydajna. Z 3. łatiwej będzie wybrać dane konkretnego użytkownika i przenieść go np na inny serwer.

Ten post edytował Mchl 6.02.2010, 12:38:11

[piotrooo89]

ja obecnie rozwijam podobną aplikację. stosuje 1 przykład. i wszytskie zapytania opieram na widokach (tak tak korzystam z Postgre) i się nie przejmuje że tabela jest ogromna.

[siewca]

Rozumiem że opcja 2, przy wielu użytkownikach tworząc tabele strasznie spowolniła by bazę?
Opcja 3, po przemyśleniu nie wchodzi grę jednak. Np w bazie jest 100 userów, jeśli zrobił bym jakieś dodatkowe funkcje to musiał bym aktualizować 100 programów.
Opcja 1 niby wszystko ok. ale czy będzie to wydajne przy ogromnej ilości towaru? Macie może jakieś doświadczenie z pracą na baaardzo dużej tabeli? Czy MySQL i php dobrze sobie z tym radzi?

[piotrooo89]

z MySQL to nie wiem ale baza która ma 2,1GB na postgresie jest chyba dość pokaźna i nic nigdy mi się z tym nie stało postgres rządzi.

[Mchl]

baaaardzo duża, to jaka?

Radzi sobie tym lepiej, im lepiej baza i aplikacja zaprojektowane

[piotrooo89]

ooo i to co napisał ~Mchl jest tu najważniejsze, o ERD poczytaj.

[siewca]

Hmmm. A może zamiast MySQL postawić to na PostgreSQL? Wydaje się wydajniejsza niż przy większej ilości rekordów niż MySQL i obsługuje zagnieżdżone zapytania

[Mchl]

MySQL też obsługuje zagnieżdżone zapytania, a 'wydaje się' że 'na oko' chłop w szpitalu umarł

Jak źle sobie poustawiasz tabele, napiszesz marne zapytania, źle skonfigurujesz serwer, to i Oracle będzie Ci kuleć. Jeszcze raz pytam, ile to rekordów będziesz miał w tabeli (i ile bajtów na rekord?).

[siewca]

Jeszcze nie ustaliłem jakie dokładnie będą pola i o jakiej wielkości. To będę wiedział projektując magazyn.
Co do ilości rekordów to wszystko zależy ilu będzie userów i ile będą wrzucać towaru ale myślę że po 6 miesiącach będzie to ok 5 tys i będzie rosło.

Wiesz, mi też 'wydaje się' że 'na oko' chłop w szpitalu umarł ale po to jest ten temat żeby zastąpić słowo 'wydaje się' słowem 'wiem że'

[Mchl]

Nie widziałem jesze testu, który by wskazywał na wyraźną przewagę Postgresa nad MySQL. Wybierając miedzy tymi dwoma należy raczej wziąć pod uwagę nie wydajność, a dostępne funkcjonalności i własne doświadczenie.

[siewca]

Jeśli chodzi o doświadczenie z bazami. Na MySQL zrobiłem parę serwisów nieruchomości z ofertami, magazynów itp. Ogólnie mają się dobrze i działają do dziś
Przed przystąpieniem do pracy z Postgre musiał bym poznać jej możliwości i różnice.

[Mchl]

Zawsze możesz pisać aplikację tak, aby mogła działać z jednym i z drugim (PDO, ORM, itp)