Cześć, tworzę aplikację do fakturowania.
Zatem ogólną ideą jest posiadanie dwóch tabel:
Invoice (ID, Date, CustomerAddress, CustomerState, CustomerCountry, VAT, Total);
InvoiceLine (Invoice_ID, ID, Concept, Units, PricePerUnit, Total);
Jak widać, ten podstawowy projekt prowadzi do wielu powtórzeń rekordów, w których klient będzie miał te same adresy, stan i kraj.
Alternatywą jest więc utworzenie tabeli adresów, a następnie nawiązanie relacji Adres <-Faktura.
Myślę jednak, że faktura jest niezmiennadokument i powinien być przechowywany dokładnie tak, jak został utworzony. Czasami klienci zmieniają adresy lub stany, a jeśli pochodzą one z katalogu adresów, który zmienia wszystkie wcześniej wykonane faktury.
Jakie jest twoje doświadczenie?
W jaki sposób adres klienta jest przechowywany na fakturze? W tabeli faktur? tablica adresów? albo coś innego?
Czy możesz podać wskaźniki do książki, artykułu lub dokumentu, w którym omówiono to bardziej szczegółowo?
Odpowiedzi:
8 dla odpowiedzi № 1Zdecydowanie odradzam przechowywanie takich danych klienta na fakturze.
Zamiast tego miałbym strukturę taką jak:
Tabela klientów z kluczem podstawowym id
Tabela adresów klientów (ponieważ każdy klient może mieć różne adresy w czasie), z identyfikatorem klienta jako kluczem obcym
Tabela faktur z polem adresu, które jest kluczem obcym do tabeli adresów klienta.
BTW, rozważyłbym dodanie pola VAT na pozycję. Istnieją kraje, w których istnieją różne stawki VAT dla różnych rodzajów produktów.
1 dla odpowiedzi nr 2
Większość standardowych baz danych produktów / zamówień będzie miała
a products table (ProductId, product info fields)
a customers table (CustomerID, customer info like address etc)
and an orders table (OrderNumber, CustomerID, date, etc)
Następnie elementy zamówienia stają się tabelą relacji wiele-wiele między zamówieniami a produktami.
orderItems (OrderNumber, ProductID, quantity, purchasePrice, vat, etc)
Aby otrzymać pełną fakturę, możesz wysłać zapytanie o zamówieniatabela i połącz ją z tabelą OrderItems. OrderItem zwykle ma cenę zakupu, ponieważ cena w tabeli produktów może ulec zmianie po utworzeniu zamówienia, a informacje te są często przydatne do przechowywania.
0 dla odpowiedzi № 3
Rozważę zrobienie tego z trzema tabelami: Customer, Invoice i Address, ale skonstruuj go tak, aby po wprowadzeniu adresu nie był nigdy aktualizowany ani usuwany, a jedynie przestarzały. Możesz mieć IsDeprecated lub IsActive pole boolowskie w tabeli adresów. Następnie, gdy tworzysz fakturę, faktura prowadzi do identyfikatora klienta ORAZ do identyfikatora adresu używanego w tym czasie. Gdy klient zmienia swój adres, tworzysz nowy rekord z nowym AddressID i przestajesz używać starego z polem logicznym. Lub jeśli naprawdę chcesz prowadzić dobrą dokumentację i / lub kiedykolwiek będziesz musiał wyszukać te dane, możesz mieć AddressActiveStartDate i AddressActiveEndDate, ale to sprawi, że zapytania będą trochę bardziej skomplikowane.
W ten sposób nadal przechowujesz wraz z nim stary adresnadal jest powiązany z klientem w celach informacyjnych, jednocześnie umożliwiając klientowi posiadanie więcej niż jednego adresu wymienionego na liście (np. jeden do wysyłki, jeden do fakturowania).
W razie potrzeby możesz dodać więcej tabel, np. Product, InvoiceLine, Stateitp.