Witam.
Pytanie czysto teoretyczne. Czy jest jakieś inne wyjście, nie korzystając z tabeli pomocniczej, aby połączyć np.: zamówienie z zamówionymi produktami?
Coś na wzór sklepu.
0
0
W systemach ERP spotykam się jedynie z rozbiciem tego na kilka tabel:
1 - nagłowek dokumentu
2 - pozycje na dokumentach
3 - n - inne tabele powiązane VAT, ceny, status dokumentu/jego typ.
Jeśli miałoby to być na jednej tabelce byłoby to mega niepraktyczne.
0
To zależy z jakiej bazy danych korzystasz. Np. w MongoDB to chyba nie ma problemu umieścić wartość tablicową. Jeśli chodzi o relacyjną bazę danych (SQL) to potrzebujesz pomocniczej tablicy by zaimplementować połączenie wiele-wiele. Natomiast jeśli każdy element tablicy "zamówiony produkt" będzie przyporządkowany tylko do jednego zamówienia to nie ma problemu, w zamówionym produkcie umieszczasz referencję do zamówienia. Ewentualnie wchodzi ewentualnie w grę możliwość duplikowania "zamówionych produktów" dla każdego zamówienia, zmieniając tylko numer zamówienia. jak zamówiono.
0
Czyli jest "niby" inne wyjście, ale i tak to wymaga dodatkowej tabeli, ponieważ:
- Jeżeli zrobimy tabele Zamówienia i Produkty to trzeba zrobić tabele pomocniczą Zamówienia_Produkty w których wystarczy id_produktu i id_zamowienia + ilość i cena.
- Jeżeli zrobimy tabele Zamówienia i Produkty to trzeba zrobić tabele ProduktyNaZamowieniu, w których będą całe dane na temat produktu (skopiowane) + kolumna z id_zamowienia, ilosc, cena.
Druga opcja pozwala zachować historię jeżeli jakaś informacja na towarze została zmieniona. W pierwszym przypadku dostajemy zawsze aktualne dane produktu.
REASUMUJĄC
Wszystko sprowadza się do tego samego rezultatu, ale co jest lepsze w przypadku oprogramowania tego? Trudniej jest ogarnąć CRUD biorąc pod uwagę 1. punkt, czy 2.?
0
Zawsze jest inne wyjście... Możesz mieć w tabeli zamówienia tylko dwa pola: id i xml. Ale po co sobie utrudniać?
0
Podejście 1 jest lepsze z tego względu że masz w miarę zachowana atomowosc. W drugim podejściu łamiesz postać moralna bazy. Po co przerzucać jakieś dane które masz w innych tabelach? Wystarczy informacja jakie zamówienie i jakie produkty na nim wraz z ich ilością.
0
No niby tak... Idąc głębiej, kopiowanie tych samych danych jest po to, aby zachować historię i spójność.
Przykład: myszka komputerowa (id 1) - wszystkie kolory (niebieski, czerwony, czarny). Po 3 miesiącach stwierdzamy, że jednak zrobimy kartotekę, w której będzie określony kolor. Dobrze by było zrobić 3 nowe, ale różni są ludzie i po co. Bierzemy myszkę o id 1 i zmieniamy na myszka komputerowa czarna. I teraz pytanie: Jaką myszkę sprzedałem 3 miesiące temu? Zamówienie pokaże, że czarną, ponieważ zaktualizowaliśmy ten produkt.
Ja wiem, że się czepiam szczegółów. Ja wiem, że to zależy od skali projektu, ale jakiś argument za i przeciw jest ;)
0
AdamWox napisał(a):
No niby tak... Idąc głębiej, kopiowanie tych samych danych jest po to, aby zachować historię i spójność.
Przykład: myszka komputerowa (id 1) - wszystkie kolory (niebieski, czerwony, czarny). Po 3 miesiącach stwierdzamy, że jednak zrobimy kartotekę, w której będzie określony kolor. Dobrze by było zrobić 3 nowe, ale różni są ludzie i po co. Bierzemy myszkę o id 1 i zmieniamy na myszka komputerowa czarna. I teraz pytanie: Jaką myszkę sprzedałem 3 miesiące temu? Zamówienie pokaże, że czarną, ponieważ zaktualizowaliśmy ten produkt.
Ja wiem, że się czepiam szczegółów. Ja wiem, że to zależy od skali projektu, ale jakiś argument za i przeciw jest ;)
Z tym, że musisz pamiętać, że wystawiając korekty wszystkie dane o towarze musi pobrać sobie z fakturki, a nie kartoteki towarowej, bo wyjdą cyrki :D
0
@Lilpri: No bardziej to podchodzi pod faktury i kontrahentów, ale przykład jest, że rozwiązanie daje troszkę więcej info i wiecej możliwości