New answers tagged

3

I think it is a sound design, based on what is called an associative entity. To query: Select A.FieldList..., B.FieldList..., C.FieldList... From A Join AB On AB.AID = A.ID Join B On B.ID = AB.BID Join BC On BC.BID = B.ID Join C On BC.CID = C.ID


1

Just answering your specific scenario. I would create a table for employees and the common attributes they have. Name, DOB etc. I would then create a table for thier skills or qualifications. I would create a foreign key linking to the employee table and use a name/value pair. So you have something like: Empid, qualification, value 1, drivers license, ...


2

I've just recently answered a similar question here. What you want is a People table containing data common to all people contained in your DB with other subsidiary tables providing the additional data unique to different roles some of those people play in the operation of your service. The linked question and answer should provide the details you need. If ...


0

If you are getting the LOWER('Meteora Breaking The Habit') portion of the query from a source that it outside your control, then I would recommend keeping your song/album table structure (although remove album_id from song table), but include a 3rd table: CREATE TABLE ALBUM_SONG ( album_id, song_id, album_song_name -- this would be album.name || song....


12

Yes, many-to-many (M:N for brevity) relationships (which usually are of great significance in business contexts of very different nature) are scenarios that a database practitioner faces all the time. They are quite common and, when properly implemented, they do not introduce harmful redundancies. The objective of a relational database modeling exercise ...



Top 50 recent answers are included