Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am developing a small system where I have to record incomes and expenses of the company, and even I can not determine if the income and expense table should be in one table or in separate tables.
The design of the database must allow the system to generate a report of income and expenses by date (in column incomes and other expenses).
I would like to explain what would be the advantage or disadvantage of having them together or separately.
If they both store the same fields of information, there's no reason why you can't put them both in the same table with a field marked TransType that would be set to I for Income or E for Expense. Or, you'd know the difference based on whether the value is greater than or less than zero. This way, you could report them separately if necessary.
I'm imagining a single table with a transaction date, account, and amount. The expenses would be negative and the incomes would be positive, but the best way to define incomes versus expenses would be the description of the account that the transaction is posted to. There is no need to build a separate table for each since they are storing the same type of information, and you can easily just grab the income or just grab the expenses by looking at the sign of the amount field. You could even include a type field to differentiate, if you wanted.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Ok, maybe it's no the best title for the question, but this is the case.
I'm working on a project that already has an e-commerce. And part of the database looks like this. Everything works perfectly.
The problem comes with the references, if a user buys a product the shopping cart is closed, but if then the product is deleted or it's price changes the order becomes totally corrupted.
I've read this text -> Database Design for Real-World E-Commerce Systems
but I can't see the solution here.
What is the best way to do this. How big companies deal with this problem.
I mean what I need is to store all the details of an order with the data it had at the purchase moment.
There are different ways to solve this. One approach is to have a price history table rather than a price column that changes periodically. When you create an order you create it for a given price and given product. When you need to change the price of the product, instead of changing the value of the price column, you enter a new record in your price history table so future orders can then take the new price. Another approach is to decouple the product price information from the order. Rather than take the price from the product table, you have a column for unit price in the order table and the current value for the price is saved there.
As far as deleting products, it depends again on your situation. Generally it's not a good idea to delete rows that are needed for historical information. So if you no longer want to sell a product, rather than delete the record, you could have a column that has the availability of the product set to false. So previous orders would still relate to that product but new orders wouldn't be able to add it.
Every instance of every field in a table should have a 1:1 relationship with that instance of the table.
The problem is that the Price has a 1:1 relationship with the Product, which is good. But it should also have a 1:1 relationship with the Cart. And, since the price can change over time, it does not.
Two possible solutions: 1)Put a Timestamp on the Purchase, and keep all HistoricalPrices, then select the proper Price for the time of the purchase. This has the advantage of being able to tell exactly why the price changed, but can be extra work. 2)Add a PurchasePrice field to the Shopping_Cart_Products table. Assign the PurchasePrice value for that instance of that table at the time the purchase is made.
You have a few choices, if the products change while they're sitting in carts:
You update the cart and notify the user of the reason why.
You put all the information you need into the cart and work with that during checkout instead of the live product data.
Solution 1 requires you to do a sanity check at least once at the end of the checkout, to see if the cart is still valid. Solution 2 means that people may buy products that are somehow outdated.
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 6 years ago.
Improve this question
Say there are two modules users and status. I split these modules in following 2 cases
Here is case-1
Here is case-2
I am trying to understand which database design lowly coupled and should be adopted according to the Software Engineering Design principals? Particularly interested to have comments that which approach is better by considering re-usability. I mean in future which approach can be re-used easily & effectly to any other software design
Both your cases have consistency issues rather than coupling/cohesion issues.
First, both your cases allow for a department to have a limitless amount of statuses. This might not make sense if, for instance, the status represents whether the department is open or closed. If departments may only have 1 status at any given time, your primary key for an status must be dept_id (in which case it should be within the departments table as a foreign key to the table with the available statuses instead), this may be incorrect depending on what you are modelling. The second case, however, is worse for consistency because it allows you to have an unlimited amount of values for the variable status (There is no table to define the valid values for status, so this case allows you to have typos even, for instance a department with status "opne" instead of "open")
Secondly, the users table has no relationship with the rest of the data, which may not make sense again (users can't be members of any department, etc). In the first case, users have no status and in the second case it is related to an status table... Neither case (for the users table) has more or less coupling than the other (because it has no relationship with anything else in your model), but you need to check whether you want users to have an status (and what is that status, whether it should be selected from a fixed list of values or not).
We don't have much to go on about analyzing coupling/cohesion in both of your cases. You must better understand what you are trying to model and should first worry about ensuring consistency.
Here's an short but interesting blog post about coupling/cohesion if you want to read some: https://thebojan.ninja/2015/04/08/high-cohesion-loose-coupling/
Hope it helps!
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 7 years ago.
Improve this question
I am kind of confused when I question like "what is decomposition?" and "how can you decompose your database and data?"
Can somebody give me a clear explanation for the questions above?
Thank you.
Suppose we have a schema, Lending-schema
Lending-schema = (bname, bcity, assets, cname, loan#, amount)
A tuple t in this relation has the following attributes:
t[assets] is the assets for [bname]
t[bcity] is the city for t[bname]
t[loan#] is the loan number made by branch t[bname] to t[cname].
t[amount] is the amount of the loan for t[loan#]
If we wish to add a loan to our database, we need a tuple with all the attributes required for Lending-schema.
Thus we need to insert
(SFU, Burnaby, 2M, Turner, L-31, 1K)
We are now repeating the assets and branch city information for every loan.
Repetition of information wastes space.
Repetition of information complicates updating.
We need to change many tuples if the branch's assets change.
So after analyzing this
We know that a branch is located in exactly one city.
We also know that a branch may make many loans.
Another problem is that we cannot represent the information for a branch (assets and city) unless we have a tuple for a loan at that branch.
Unless we use nulls, we can only have this information when there are loans, and must delete it when the last loan is paid off.
So if we decompose into two schemas
Branch-customer-schema = (bname, bcity, assets, cname)
Customer-loan-schema = (cname, loan#, amount)
These two tables are formed after decomposing the main table.
In Short : Dividing a table into multiple tables is Decomposition. Our decomposition should be a lossless-join decomposition
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
This may be a classical requirement. Two key concepts objects and items, a time-change demand, the items can changed very quickly.
Such as a person have so many salary items, and these items will be added and changed or deleted.
Our solution is so simple, it's a 500 columns table, and map items to columns.
This beyond to hard code. This solutions have so many disadvantage.
**What's the classical solution about this requirement**
As I gather from your question, this is a classical one-to-many (1-M) relationship. The one side is the (object) and the many side is the (item). The item should have a column that points to its 'parent object'. This is column could contain the value of the Primary Key of the parent table (usually referred to as Foreign Key). The child table (the item) could have validity period (such as start date, end date) as well as other control columns in addition to the business columns (such as salary amount, etc.). This design is typical in Normalized database modeling.
There are many advantages of this design. One of them that pertains to you case, is that you don't have to have large number of columns, instead, you'd have several rows which allows you to fetch just what you want to satisfy most business queries. Similarly Create and Update operations will deal with much smaller rows, hence increasing the performance of the application.
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 8 years ago.
Improve this question
Let's say I've got a web application that is a store of some kind. I have a table that holds all of the monetary transactions.
custid, orderid,amount paid...etc
And this table is being used for sales reports and what have you.
Now we want to give a customer a credit of some kind, either a gift certificate or a refund.
is it a bad idea to just enter it in the same table with a -amount? Or is it better to put these in another table?
Is there a major flaw in setting the site up with this table structure to begin with?
I've set up a few systems like this but haven't had much feedback from others, how do you guys usually set up your tables for store like db's.
thanks,
Ken
Typically there would be a reason why you'd give a refund, so already the schema for this use case is different than that of a purchase.
So now your choice is should you store the refund in both places? It always makes me uncomfortable having multiple sources of the truth.
You will need to decide how you are going to work out the overall balance of a customer, storing the in/out in multiple places is going to make this harder than it should be. So you're back to having a single store for money in/out and a separate store for meta-data about a refund.
Purchase
--------
PurchaseId
ItemId
CustomerId
Payment
Refund
------
PurchaseId
Reason
Obviously there are other fields, as you say -ve values for refunds
As it happens this is nearer a real world paper ledger and separate 'refunds' book.
I've never had to do this , this is just me thinking out loud :-)
There are a hundred ways to skin a cat, but here are a few "food for thought" points:
You could potentially add a "Refund" column that would contain a "1" if it is a refund, or a "0" for a sale. You then have to decide whether to keep the amounts all as positive values (and just subtract if there is a "1" in the refund column) or if you want the amounts to be positive and negative and just look at the refund column as more of an indicator (possibly for reporting purposes)
You should consider your purchaseID! Do you consider it more of a "transaction ID" or an "order number". It may seem like there is no difference at first, but a transaction ID would have a unique ID for every entry that would mean a purchase would be 0000, and the refund would be 0001 (for exmaple). If you treat it as an order number, the purchase would be 0000 AND the return would also be 0000 so that you know the refund is related to that specific purpose.
Expanding on my previous point, I would suggest considering a separate Refund table that would contain a unique RefundID, CustomerID, OriginalPurchaseID, ItemID, Amount, and Reason column (and perhaps PaymentMethod). Your Sales table would remain pretty much the same: (unique) PurchaseID, CustomerID, ItemID, Amount, PaymentMethod. Also, be careful with your ItemID as the current setup would require a separate entry (with repeated purchaseID) for EACH itemID.
Hopefully this helps a little bit and can guide you to a better structure. Don't be afraid of having multiple tables, just make sure that you have a good method of relating them!