Open DioFun opened 3 months ago
Some questions I have reading this database schema, though I might be lacking some context so they might sound stupid:
I'm not requesting any changes to this proposition, it's just to try to understand it a bit more
One more because I felt it was not enough:
1 month subscription
and you buy a quantity of this article. Might be overkill thoughI'll try to answer the questions with the different discussions we had during the creation of this model.
The payment_method database aims to list the different method of payment, the goal is to allow to add, remove method with views. So we link a sale to his payment method. A payment method can't be hard removed because a previous sale must keep the tracking of the method used.
The "details" table are many to many join tables with an additional field for the quantity.
We want to process articles and subscriptions differently. Articles are in a dropdown selector where the seller can choose wich article he is selling. On the other hand, we want to apply the different offers of subscription not directly on the view but in the data treatment process.
A refund would be linked to a sale because we do not want to refund something that has not been bought or refund many times the same thing.
We thought over this during the brainstorming and it's still under considerations but invoices has to be kept for 10 years at least legally. Maybe, the sales, refunds and other information must be deleted after about a year.
As it 's not written on the issue, article can't be edited, we can only soft delete it and recreate it if we want to change the price. As a consequence it doesn't impact refunds and sales.
I think 3 answers the question
If something is not clear, feel free to ask any questions.
(Cette conversation est sponsorisée par DeepL)
Même pas
Thanks for the clarification!
REFUND_ARTICLE_DETAIL
and a SALE_ARTICLE_DETAIL
(same for abonnement). My understanding is that for a refund, the total price will be negative (money going out) and for a sale, the total price will be positive (money going in). We could implement this logic in the service instead of the db:
Il a été envisagé de fusionner les tables "sales" et "refunds" mais @nymous a conseillé de ne pas sur-simplifier le modèle avec comme illustration une entreprise (je ne sais plus laquelle) qui avait des problèmes suite à une telle simplification. Pour le point 4, nous ne rachetons ni ne vendons pas de routeurs.
Subscription management
Features
Database modelisation