As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have two tables in my db: Customers and Subcontractors.
Now it appears that some customers can be also subcontractors.
What I decided to do is to create a base table (super type) that holds the common data and then complete the relevant info for each type (customer, subcontractor) in other table. It will be something like this:
NEW_TABLE<------Customers
<------Subcontractors
The problem is that I don't really know what to call this table. Is the name "Partner" the best option?
Agreed with the other responders. More information about the domain is needed before getting really useful answers.
But I'd suggest ThirdParty or ExternalParty, since I'm assuming Customers and Subcontractors are external to your business. Internal parties could be User, InternalParty, etc.
I think you've tagged this question properly.
Hope this helps.
Nobody can answer your question without knowing the domain.
It can be partner, contact, company.
'Party' may be a good name. You can find this and this interesting. Or just google "Database Party Model".
IMHO, there are two main options:
Have a single table called third_party that has a party_type column of either 'customer' or 'subcontractor' (and others and time goes by, like 'supplier' etc).
The details are largely contact details, which are common to all third parties
Have two tables like you have now, but store the common data in a separate table, for example contact_details, and have a foreign key from both tables to that details record. When a customer is also a contractor, both records would point to the same details record.
I prefer option 2, because it allows different relationships to exist for each type.
I'd call it SubcontractorBase, but as Peri points out it is hard to say without knowing the domain
What about having a single table, with all of the options (however named) as BOOLs so that you could easily indicate when a party belongs in more than one group (you'd also be able to add categories as needed in the future)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Please help, I am working on a new project for Manhours Timekeeping. We have a production table called EmployeePunches where there are fields like EmployeeNumber,BusinessDate, Clockin, Clockout. Now the 3rd party application is looking for our old setup of manhours table where there are EmployeeNumber,BusinessDate,Time,Time_Event. The EmployeePunches table is fixed and they dont want to edit it. while the 3rd party application that access old manhours table is too expensive and will consume time to customize.
My recommendation is to create a new table, this newtable will get the data from EmployeePunches while the fields will change to manhours table where there is time_event - I=in and O=out to satisfy the requirements of the 3rd party application.
My question is what would be the best implementation for this type of scenario. Badly needed experts help.
Thank you in advance.
The best implementation is to use a view. This makes sure that the underlying data is always aligned with the newest data in the table.
Backwards compatibility is a very good way to use views.
If you have a performance issue with the view, then investigate indexed views. These allow you to build indexes on views to improve performance.
You don't tell what the data dictionary of EmployeePunches neither provide sample data, but it looks like a view is the best approach here. A simple SELECT with the fields and change time_event.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Usually, join (many to many) tables are named after the types they join - if a table joins users to roles, its name would contain both user and role (i.e. user_role).
Is there a naming convention that defines which word / type should come first?
EDIT: Having a convention means knowing the name without having to remember it. Please, try to understand that before voting for closing the question for being not constructive.
In 1:n it is user_role.
In m:n I'd use the more important one first, and in this case the stronger term is user IMHO, as you usually assign roles to users, not vice-versa.
The role does not make sense without a user, but a user makes sense without a role.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
One of the disadvantages people point to with using foreign keys in a relational database is the overhead of making sure the parent table exists before doing any insert operation. (Example). As your database and operation grows, this effect is amplified. Does anyone know if large sites on the web use them then? If so, how do they get around that extra overhead? If not, as your development team gets bigger, it seems that that could cause a lot of potential bugs/conflicts/miscommunication/orphan-rows.
Any insight?
I work for a telecom, yes they do, often the cost of FK is too small compared to severity one major incidents (hours of time lost investigating, patching ...) that can be caused by accidents due to lack of FK checking.
This depends on your definition of "large site": If for example Citigroup online bank is a "large site", I guess they do.
What I mean by this example is, that the use (or not use) of foreign keys, access by stored-procedures-only etc, depends on the requirements of the business logic (and maybe its legal framework) more than on technicalities only.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
As the title suggests, I'm pondering whereabouts in my app to put some business logic and would be interested in some opinions. It is a simple app which downloads pages from the web and stores them in a sqlite database.
Business logic dictates that the app can only store one entry for a particular URL. I have set up the database so URLs have to be unique and currently rely on this to enforce the logic. I.e. if an attempt is made to insert a web page which is already stored, an error code is returned from the database and the user is informed.
However, I can't help feeling that the 'app layer' (java code) should know about this rule too - it doesn't feel right to rely on an sql error code for this.
I think I have three options:
1 have the database enforce the logic
2 have the app layer enforce the logic and remove the unique constraint on the database
3 have the logic in both places
No 2 is the least desirable to me as the database would not be in control of its own integrity. No 3 would require some duplication, but would mean the same database could be used in other apps and its integrity would be intact.
Would love to hear some views on this.
Thanks in advance,
Barry
The app layer should enforce the logic. This is just easier for design. Database does data things and business logic layer (app layer) does the logic. Keep things separated and make your life simpler since when you need to change a data thing you change it in the database and any logic changes get changed in the app layer. This is sort of a highly debated topic so be prepared to receive different answers.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The company I am working for calls manual database changes (ie., writing a SQL update/insert/delete) a "data hammer". While the term makes sense, I have yet to find any other organization or group that calls it by this name. A search here on SO yields no results.
How do you refer to manual database changes? Is there a standard term?
I usually hear it referred to as 'writing a query' or 'updating a query'.
I don't think that there is a professional term for this. We just call it "manual database change".
Personally, if I delete all the rows I call it "blatting" the database. If I manually force data into it then (just in my head) I call it "shoe-horning" the data into the database.
I think I need a cool term for updating it though. I used to say I was munging it, but that's been stolen by the deployment applications meaning token replacement, so I need a new term, otherwise I'm in danger of being understood outside my organisation.
How about calling it "hacking" the database? :)
Back-end changes. This is of course different from backside changes, which are what happen when you spend 8-10hrs a day in an Aeron.
"Ad-hoc query" is sometimes used. As opposed to a stored procedure.