On Fri, Jan 28, 2005 at 09:18:54AM +0100, A.L.E.C wrote:
hunter wrote:
table cashlinks ( covenant integer /id obciążenia w cash payment integer /id wpłaty w cash )
Ale idąc o 3 kroki dalej: masz F/V chcesz znaleźć czy/które pozycje zostały opłacone:
masz id z invoice_contents i pupę gołą bo nie masz powiązania z cash/cashlinks. Żadnego powiązania poza opisem w cash.
rozwiązaniem tego problemu może być po prostu dodanie kolumny cash.icontentid, a wtedy nawet możnaby chyba wywalić z cash kolumnę invoiceid (choć jej wywalenie spowodowałoby spadek wydajności).
Tak, ale będzie w kierunku postaci normalnych :) A już tak na zupełnie serio: iconentid jest unikalne w obrębie danego invoiceid (jest w sensie powinno być w ładnym modelu) tzn samo contentid nie powinno dawać nic :)
A swoją drogą dodać warto :)
Twój model zakłada: dodać120, potem martwić się jak to rozksięgowąć. "potem" to złe założenie imvho. No chyba że zrobimy UI tak aby wymuszał powiązania w cashlinks.
trochę trudniej byłoby, gdy pozwolimy na opłacenie jednego obciążenia kilkoma wpłatami, czyli przy abonamencie 100,- user wpłaca 50,- ale myślę że i z tym bysmy sobie poradzili, choć może nie w jednym zapytaniu.
Oczywiście jeśli user dokona przedpłaty, to trzebaby później jakoś dopasowywać tą przedpłatę do nowego obciążenia, ale to i w twoim rozwiązaniu występuje.
Właśnie problem bardziej w tym co chcemy osiągnąć a nie jak, więc może najpierw określmy co chcemy osiągnąć i czy normalne jest np przechowywanie 30 wpłat po 10 zł aby za 4 tygodnie naliczyć 300,- za instalacje ?
kd.