Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This is my first database schema design. I am trying to develop a small web application for my department which will be used for food cost management. And I am doing this for my learning purpose.
How the food cost management works in my department:
Total members: 15
One admin to keep record of all the cost. he will update the database on a daily basis.
Each member can order only once a day. If anyone has guest on any specific day he can order multiple number of meal.
Usually members pay their bill for a week or two in advance.
one or two persons are responsible for bringing the food from outside and they don't need to pay for their lunch. Transportation cost is also given to them. their food cost+ transportation cost is distributed equally to other 15 members expenses.
Database queries:
From admin perspective:
he will manage/add the daily order. (Table: orders)
he will add the payments for all the members which will be credited against respective member's "Balance" (Table: payments)
he will be able to see an overview of all members' order/cost history and their current balance in a chart for one month at a time.
If any member has negative balance or less than a specific amount of money, it will be notified to admin dashboard.
From member perspective:
he will be able to see his current balance and order/cost history for last one month at a time.
he will be able to see last x number of payment history he made.
Based on the queries I mentioned above I tried to design a database schema which looks like the diagram below:
Elaboration of some attributes:
EPlatenum: Number of extra plate of food brought besides number of plate ordered.
Eplatecost: cost for extra plate of food. this cost is distributed equally among 15members individual cost.
EPersonnum & EPersoncost: Number of extra person involved in bringing the food and their total cost. the cost will be distributed equally among 15members individual cost.
TransCost: transportation cost. the cost will be distributed equally among 15members individual cost.
Questions:
what are the mistakes I have made and how can I overcome them?
For my DailyList table I have used "date" as the primary key.Is it OK to use date as primary key? IF not OK, what can be the primary key here instead?
when I am going to populate a chart overview for 30 months cost/order history the database query will be huge I assume. what approach should I take to optimize the query?
I am looking forward to getting your suggestions on improving the database schema. Please help me correcting my design mistakes and overcome them. Thank you for your patience.
My first impression:
I think payment should be related to order (because user pays for specific order).
I don't know what DailyList is, but if there may be more than two with the same date (and as I can image it may be) you shouldn't use it as a primari key.
Password should be encoded with e.g. SHA (so varchar 15 is to less).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Consider the following database design (irrelevant columns and tables removed):
Each time a recurring payment is due for a subscription, I intend to add an invoice record and subsequent payment record.
However, given orders can contain both one-off purchases, and subscription purchases, is it normal practice to reference the original order_id when generating new monthly invoices?
My hesitation, if not clear, is that the original order record may include items that are not subscriptions, and as such, are not relevant to the recurring invoices.
I'm not sure this is a matter of opinion.
The original order contains the order for the subscription. That it contains other information is rather irrelevant. You care about the order where the subscription first appears.
Keeping the original order id seems reasonable. In fact, when an invoice is created it is probably a best practice to have information about the original order for the items on the invoice. Otherwise, it becomes much more cumbersome to check the lineage of the items -- something that might be quite important for auditing purposes and other reasons.
Redundant info is (usually) a no-no in database design.
If you need an 'extra' JOIN to get the desired info, so be it. This is rarely a reason to clutter the schema with an extra column.
My thoughts:
Any order item can be 0 cost.
A subscription item is 0 cost order. Item should generate an entry in a table which relates customer and service bought (at 0 cost) from which an invoice can be generated in whatever periodicity and amount the contract states.
The only difference between an invoice and payments is direction. Have one table with sufficient information to identify the invoice for (sum of payable order items and order id) or subscription items (customer id and service id).
The customer will not identify the payment unless you manage payment collection by direct debit, so you have to code for allocation of funds received (refunded, refused etc.).
Do you really need an invoice (isn't that the same as an order if every order is billable?).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
This question is an extension/expansion of an already answered question on StackOverflow: Database Design for Invoices
However, I'd like to expand on the idea and find out the correct way to allow customers to pay for invoices using some type of installments (monthly payment) system.
In the answered question, the voted answer utilized a database schema that had the following tables:
Orders table: used for draft/pending orders
Orders Details table: used for line items of pending orders
Invoices table: used to represent finalized (immutable) orders and how much the customer owes.
Payments table: when a customer makes a payment the total amount goes in here.
InvoicesPayments table: this shows how much of each payment should apply to a particular invoice. This table is needed because sometimes payments can apply to more than one invoice.
(for sake of simplification and because this question's focus is the table design I've left out details like triggers, etc.)
How can I allow for invoices to be broken up into monthly installments? The requirements are as follows:
At the time the order is placed the customer will be able to select how much they want to pay as a down payment and then pay X number of monthly installments until the balance is paid.
For now we can ignore things like interest rates.
Sometimes a customer will make a payment that will cover more than one monthly payment. For example, lets say they forget to pay one month and next month they pay for the current month and the past month in a single payment.
Any help/guidance you can offer would be most appreciated. Thank you!
-- AFTERNOON UPDATE --
After considering the responses so far and doing some tinkering on my own, what do you think about having a schema like the following:
In the above proposed schema, all invoices will have a ScheduledPayments record. If the invoice is due all at once (pay in full), it will have one record in there. If the invoice is paid in installments it will have X number of records for each payment (plus any down payment).
Then, when a payment is made, a record is added to the payments table and one or more records is added to the relationship table "ScheduledPaymentsPayments" which will connect a payment to both invoice(s) and monthly payment(s).
What do you think of this solution? Do you foresee any problems with it or can you suggest any alternatives that might be better?
You can add columns to the Orders table for DownPaymentAmount, MonthlyPaymentAmount, NumberOfMonthlyPayments, and that satisfies the first requirement.
The third requirement looks like the database can already handle it with the InvoicesPayments table, with the logic being handled in the app layer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What is the best way to store customer balance in MySQL.
I am creating an accounting application and I am faced with the decision whether to save each customers account balance in a table row or calculate it when needed.
I would like to know the best approach and why it is the better method.
you should store all of the transactions rather than just the current balance. That way you have history, and you can run different aggregates on it rather than just "final balance."
and
Use decimal(10,2). float is susceptible to rounding errors, see here "http://dev.mysql.com/doc/refman/5.1/en/numeric-types.html"
It depends.
The advantage of always calculating the balance is that the balance will always be correct. The disadvantage is that account balances can take a long time to calculate, and you'll have to make the calculation every time you need the value.
The advantage of storing the balance is that retrieving the balance is more or less instantaneous. The disadvantage is that, if you're not careful, the balance can go stale; that is, it won't reflect the actual balance. Storing the balance requires that you always keep it maintained as the correct value when anything that might affect the balance (sales, returns, payments, etc) changes.
Think of a stored balance as a cached value, with all of the advantages and problems it entails.
If you do store the balance, it should be updated in a database transaction along with the thing that is changing the balance. That way, you won't have problems with race conditions where someone retrieves an old balance, but the new item that changes the balance has already been recorded.
It depends on your problem. I recently designed the same thing, so what I did is:
Created a table user_account that has one-to-one relation with user table. This user_account holds 'quick' information related to user balance like remaining balance, last update, expiry date etc.
I also created a table transaction (linked with user, user_account or may be order table) that hold all the transactions against user account. Lets say a user bought something today cost 20$ i am saving all these details in transaction table. So that in any point of time I can track when and why a user used his/her balance and where.
So there was a reason of using quick information word for user_account table. What i meant by this was, if you just quickly want current remaining balance of a user, just query user_account table to get balance of that particular user but if you want high level details like when and where he/used credit query transaction table.
My question is more of trying to understand what and how I can get something done. Here's the thing:
I got a job to build this application for a school to manage student bio data, work-out and handle student information and basic finance management.
Based on requirements I got from meets with my client, I have an ERD of a proposed MySQL Database with 23 different tables. The one part I would like to understand quickly is displaying data based on school terms. There are 3 terms in a year, each with its own summaries at the end of each term. At the end of 3 terms, a year has gone by and a student is promoted or demoted.
So my question is, how can I render my data to show 3 different terms and also to create a new year working out how to either promote a student or make the student repeat the class its in?
23 different tables? I'd like to see that model.
I don't think you should have one table per term. You'll have to keep adding tables every term, every year.
Sounds like a transcript table should have term and year columns that are incremented or decremented as a student progresses through. It should also have a foreign key relationship with its student: it's a 1:1 between a student and their transcript.
I would have a separate transcript table because I'd prefer keeping it separate from basic personal information about a student. A transcript would refer to the courses taken each term, the grade received for each, and calculate overall progress. If I queried for the transcript for an individual student, I should be able to see every year, every term, every course, every grade in reverse chronological order.
I apologize if this has been asked before, but I'm pretty new to this and unable to find an answer that addresses the situation I'm faced with.
I'm trying to put together a database to run behind our company website. The database will store information on customer invoices and payments. I'm trying to figure out if I should create a field for the invoice balance, or if I should just have it calculate when the customer account is accessed? I don't want to create redundant data, and don't want to have the chance that somehow the field wouldn't be updated, and would thus be incorrect...but I also don't want to create to large of a burden on the server - especially if we pull up an overview of customer accounts - which would need to then calculate the balance of every account. Right now we are starting from scratch, so I want to set it up right!
We are anticipating having a couple hundred customer accounts by the end of the year, but will most likely be up to a couple thousand by the end of next year. (Average number of invoices per customer would be roughly 2-3 per year.)
There are probably other things to consider as well. For example, what if your invoice consist of ID's of products in another table... and the prices of those other products change? When you go to generate the invoice, you'll have the wrong total in there for what the guy actually paid 6 months ago. So if its a situation like that, you'll probably want to store the total on the invoice. And I wouldn't worry too much about doing a little math if you go the other route, it's not likely to be a huge bottleneck.
Yes, remember that items/goods could and will change their prices over time. You need to have the invoice balance as of the day of the purchase. Calculating the balance on the fly could lead to wrong balances later on.
Invoice balance is essential data to store, however I think you meant account balance since you referred to that later.
Storing the account balance would be denormalizing it, and that's not how accounting databases are typically designed. Always calculate account balance from invoices minus payments. Denormalizing is almost always a bad idea, and if you need to optimize in the future, there are other places to cache data that are more efficient than the database.
In your use case, a query like that on a few thousand rows would be negligible anyway, so don't optimize before you have to.