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.