[Spake]

Mirki, pytanie do #php i #bazydanych #mysql , czysto praktyczne.
Załóżmy, że mam tabelę z zamówieiami w CMSie napisanym przez siebie.

Czy zamówienia niezrealizowane upychać w jednej tabeli z tymi zrealizowanymi, czy zrobić osobną tabelę na "archiwum" zamówień?

[B.....d]

@Spake: Nie widzę większego sensu trzymać praktycznie tego samego (tylko z innymi statusami) w dwóch różnych tabelach.

[Spake]

@BunkMoreland: a szybkość działania? Z archiwum raczej rzadziej się korzysta niż z tabeli z aktualnymi zamówieniami. Nie jestem zbyt doswiadczony w tej kwestii, dlatego pytam

[macabrankov]

@Spake: w jednej, dorzuć po prostu pole statusu realizacji. w ten sposób możesz używać cały czas tego samego identyfikatora dla zamówienia.

[ludzik]

@Spake: wydaje się że w odniesieniu do zrealizowanych będziesz przechowywał dodatkowe dane jak np. data realizacji,id kupujacego czy jakieś id faktury.Nawet jeśli nie teraz ro potem możesz zechcieć mieć więcej danych nt. zrealizowanych.Dałbym odrębną tabelę.

[ludzik]

@bunkmoreland @macabrankov, co Wy na to?

[B.....d]

@ludzik: Dla mnie to słaby argument żeby z jego powodu tworzyć nową tabelę. Jeśli pewne informacje są dostępne dopiero po zakończeniu całej transakcji, to po prostu robisz te kolumny nullable i tyle.

[Spake]

@BunkMoreland: @macabrankov: @ludzik: dobra, dzięki wielkie za pomoc, upchnę to w jednej tabeli

[macabrankov]

@ludzik: ludzik, do takich rzeczy jak id kupującego czy inne id musi mieć od początku dobrze skonstruowany projekt bazy - powiązania między tabelami itd., więc wg mnie jest to zbędne dublowanie. Faktury i tak może trzymać w oddzielnych tabelach (bo trzeba założyć, ze jedno zamówienie może wygenerować więcej niż jedną FV).
@Spake: Szybkość działania .. a ile zamierzasz mieć tam rekordów? Jeśli to nie będą miliony, to nawet

[ludzik]

@bunkmoreland to już prędzej dałbym tabelę z transakcjami i id do niej w tab. z zmówieniami zamiast rezerwować miejsce na dane których część będzie pusta.
A prędkość o którą pyta autor?Indeksy powinny to załtwić.

[Spake]

@macabrankov: @ludzik: dla mnie rozwiązanie @macabrankov jest lepsze.

Jeszcze osobne pytanko, czy przy budowaniu serwisu w oparciu o PHP + MySQL, używać relacji w bazie danych, czy załatwiać to po prostu poprzez PHP ?

[ludzik]

@Spake: od trzymania relacji jest baza.Bezwzględnie.

[Spake]

@ludzik: Tzn. chodzi mi o sytuację, w ktorej mam bazę użytkowników oraz bazę zamówień. W bazie zamówień mam kolumnę user_id, która precyzuje, który użytkownik złożył zamówienie. Żeby w systemie PHP sprawdzić, który użytkownik złożył dane zamówienie, najlepiej powiązać to relacyjnie w bazie czy poprzez PHP najpierw pobrać id kupującego z zamówienia a potem pobrać dane kupującego po tym id ?

[ludzik]

@Spake: relacje ustawiaj w bazie żeby dziedziny działania nie nachodziły na siebie.A do pobierania danych z dwóch czy więcej tabel stosuj joiny w zapytaniach zamiast kombinować z odpytywaniem dwóch tabel odrębnie.

[ZukColorado]

Szybkość działania .. a ile zamierzasz mieć tam rekordów? Jeśli to nie będą miliony, to nawet się tym nie przejmuj.

@macabrankov: To zależy też mocno od możliwości/konfiguracji maszyny, na której stoi baza. Na produkcji w pracy mamy tabele, które mają po kilkanaście milionów rekordów i w sumie nie ma potrzeby się do nich dotykać. Zdarzało mi się za to partycjonjować tabele z ~200k rekordów i wydajność po tym zabiegu była

[I.....n]

@Spake: kolumna swoją drogą ale klucze obce też muszą być.
A co do szybkości to miałem 100 milionów krotek w tabelach i śmiało szybko. Kwestia przemyślenia indeksów i odpowiedniego serwera.

[tatarysh]

@Spake: kolega chyba poczatkujacy z mysql / php

[MacDada]

@Spake: tak jak podpowiadają inne Mirki: jedna tabela i indeks. Ten drugi sprawi, że będzie śmigać przy selectach, a w większości przypadków będziesz właśnie selecty robić.