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.
--
Krzysztof Drewicz
Podsłuchane na pogrzebie: "Wiem, że to niezręcznie pytać o takie rzeczy w tej
chwili, ale przypominasz sobie, żeby on kiedykolwiek wspomniał coś o kodzie
źródłowym?" --- Charles Addams
