New answers tagged normalization
There is no clear answer to that. Both variants have pros and cons. Many here will advice to properly normalize data with a separate table. You might get best of both worlds with a MATERIALIZED VIEW: Properly normalize your data model, and offer an aggregated view on the data in the materialized view.
As NoSQL databases typically do not support joins, they expect you to store the data in de-normalized form. (So, throw the codd normalization rule book away. Just kidding). In this case, the thrid table better have the values duplicated something like (orderid, ordertime, [itemnames], waitername, orderserviced yes/no, servicetime, ...). itemnames can be a ...
I think this is better choice when student can choose multiple Major at a time. STUDENT (StuID, StuName) MAJOR (StuID, Major) You Second Try will be a better choice when student can choose only one Major at a time STUDENT (StuID, StuName, MajorID) MAJOR (MajorID, Major) Now one more step, I can think of here is, as Major value is some fixed set of ...
This is likely to be a many to many relationship. create table drivers ( driver_id int primary key, ... ); create table trucks ( truck_id int primary key, ... ); create table drivers_trucks ( driver_id int references drivers(driver_id), truck_id int references trucks(truck_id), primary key (driver_id, truck_id) );
Swap the foreign key so that the Drivers table has id_truck. This way multiple drivers can be associated with the same truck.
Sorry, this may not be An Answer, but I couldn't add a comment. This is surely a 'solved problem' in that hotel and reservation systems are available commercially 'off the shelf'? Why develop your own? Even if you do decide for good reason that you need to, it might well be worth investigating the data models underlying a few commercial products, if you can ...
The relationship between normalization and performance is complicated. Sometimes the pursuit of normalization and the pursuit of high performance lead in the same direction, sometimes in opposite directions. You have to look at each case carefully. More importantly, there is more than one measure of "goodness" in a database. In addition to performance, ...
You'd need a many-to-many table that maps people to companies. Something like (I'm guessing at your table definitions) CREATE TABLE employment ( person_id INTEGER REFERENCES person ( person_id ), company_id INTEGER REFERENCES company ( company_id ), CONSTRAINT pk_employment PRIMARY KEY ( person_id, company_id ) );
I think the comment in your linked question is referring to the idea that you could be using natural keys instead of generated keys for everything. But I don't think your use of generated keys in this instance is unwarranted; you want a single unique key that can reference a single row of data. I do have a question about your choice UUID's, though. They ...
The id antipattern is having a unique ID column in each table without requiring (or often discouraging) the application of alternate unique keys. The ID is generated for each new record. Why is this an antipattern? Numeric surrogate keys are fine, including when they are singleton primary keys. However, every time I have seen a schema in which EVERY ...
Top 50 recent answers are included