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.
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 last year.
Improve this question
I'm redesigning our service app, and getting rid of some really awful schema problems while I'm at it. Trying to build the replacement with best practices as much as possible.
I'm having a company table rather than just customer, as it's often useful to identify companies that are not customers (suppliers, contractors, etc etc). I'm trying to decide whether it's better to simply include a boolean field represented in the relevant part of the app by a checkbox that identifies relevant companies as customers (which would become uneditable once the customer has services attached to them), or if I should, instead, have a separate table that's basically just a single field referencing the Company ID that is in turn referenced by any child records.
This similar question asks about records that can be one of several subtypes. While the question is materially different (every policy seems to be only one of the potential subtypes, whereas Companies can be any or all of Customer/Supplier/Contractor etc) its similarity combined with the fact that it has multiple conflicting answers raises the possibility that there is no industry-wide consensus, so:
Is there an established best practice here? I'm not immediately seeing any reasons that other fields should be included in the prospective Customer table, but I'm open to the idea that there might... is that a good enough reason to go with B? Or is this a clear YMMV situation, where both options have benefits, either being equally valid?
I should, instead, have a separate table that's basically just a single field referencing the Company ID that is in turn referenced by any child records.
There are probably several attributes that apply to a customer that don't apply to a non-customer Company, so CompanyID probably won't end up being the only attribute of Customer.
So if that's the case, the clear choice is to have a separate Customer table.
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 2 years ago.
Improve this question
when we have two tables, suppose A and B,there exists one to many relationship between these two, than can there be element from A that are not connected to any element from B?
One to many relationship between relational tables is a concept that primarily means that if there is a record in table A, then it can have many associated records in table B.
For e.g. customer_id record in table A can have many loans for that customer in table B.
So 1 customer_id associated with many loan_ids in another table.
Coming back to your question, it is possible that 1 loan_id in loan_table can have multiple guarantors in guarantor_table and it is also possible that a loan does not have a guarantor associated with it. So even though there is one to many relationship between the tables it does not mean it will always have many records in table B for one record in table A.
Check this link - What is the difference of partiality and optionality when drawing ER diagrams
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 6 years ago.
Improve this question
For background, my situation is I have a database that is missing a lot of foreign key relationships. One in particular, let's call it Orders, which represents orders with a composite primary key of OrderID and LocationID. The other table we'll call OrderDetails which has an OrderID but no LocationID. In reality, it is impossible to have an order in two locations at once, so it was assumed that there was no need to have LocationID in the details table. I didn't design it, and I can't change that.
We also have to work under the assumption there will be no support to add location id to the details table for various reasons. We are also working with Oracle and a high volume database with many concurrent users in many locations. Finally, there will be minimal time to change any applications that use this table.
So my question is: is this solution is feasible, or is there anything else I should try?
Say I create an intersection table, for lack of a better name AllOrders or whatever with primary key OrderID. Now we link Order.OrderID to AllOrders.OrderID and link OrderDetails.OrderID to AllOrders.OrderID. Would it be reasonable then to fill in AllOrders via a trigger on each insert to Orders to enforce the integrity? I am assuming all applications are inserting details after orders or the changes to enforce would be minimal and allowed.
Are there any better solutions? I understand we would do this differently if in charge of designing or given more leeway for fixing, but I'm trying to make the most given the constraints.
Edit --
To clarify what I am looking to accomplish, I want to treat all orders with the same ID as an equivalence class modulo location and ensure that if any order is deleted it requires all orders with the same id deleted and all child order details to be deleted. With primary importance of no orphan details. This has to be done with minimal application changes if possible and no redesign of existing tables if possible.
Create a new table to handle the mapping going forward.
Table: Tb_order_orderdetails
Columns: OrderID, LocationID, OrderDetailsID
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