New answers tagged

2

You should consider the idea that specifications change. Today there are 50 default fields, tomorrow there could be 51. You do not want to be adding a column every time the requirements change. The reverse might also be true; what if a column is no longer mandatory or is no longer required? The sample ERD below allows the following: people can take a ...


0

I would go for option 1., but I think there is no reason for: a json string which defines the custom fields. Some databases ( eg. PostgreSQL ) have support for traversing JSON, so to get list of keys from a JSON you make: select key from json_each('{"a":"foo", "b":"bar"}'); So in your example you can just select that JSON from answers table ( via ...


0

I think you have two choices: either have one profile reference and an indicator in the user record to identify the profile type, or have two profile references and enforce your requirement using insert and update triggers. In the first case, you'll have to forego referential integrity (since your foreign key can reference two different tables), but you save ...


2

But another problem comes with the restful api. I'm not sure what is a good way to expose this kind of data. Any way you like. REST doesn't care, so long as the application state is completely captured in the hypermedia. In particular, REST doesn't care how you spell your URI. Convention is to express hierarchy in the path, and filtering in the ...


1

Every book can have several users as authors and at the same time every user can be an authors of several books. So you have an n:m relationship. No problem, that justmeans you'll need a link table that references both entities. they can also keep this association private Even less of a problem: you add visibility as another attribute to the ...


2

One possibility, not yet mentioned, is that you don't stick an incomplete record in the database at all - you just hold it as a blob (serialized by some means) somewhere (could be in the database, could be elsewhere). It rather depends on what, if anything, is done with incomplete records (this is about workflow and related). Specifically if 90% of the code ...


0

The requirement is self-contradictory: the required fields must all be optional. But okay, let's laugh at the person who wrote the spec and then move on. I think creating two tables is a very bad idea. This would mean that all the field definitions must be duplicated. It's likely that many queries would have to be duplicated -- your basic insert at a ...


3

You could have a separate table for works in progress. You would use more or less the same table scheme, just with each field set as nullable. When a record is initially created, it goes into the incomplete records table (you could have a check to put first time completed records directly into your completed records table, of course). Once a record has ...


4

The names of your tables should be BUSINESSES, TREATMENTS, CLIENTS, EMPLOYEES, APPOINTMENTS. Nobody appends "_TABLE" to their table names, just as nobody appends "_Word_Document" to their word document names. Also, we usually do not include joined fields in table designs. The fact that these fields are available is evident by the presence of the foreign ...


2

You shouldn't split a normalized table just because it have "many" fields. It will not make anything easier.


0

The question really is what system calculates the record to insert into B and the size of the B data. Any database (eg MSSQL) should be able to handle the volume of inserts you are talking about no problem assuming the object isn't huge. Updates may by a more difficult problem, but with the right indexing and locking, again shouldn't be a big problem. 99% ...


4

I'm not sure whether hotel services are "booked with the room". What about conference rooms or all-day pool passes? Hotels have customers that are not guests, so a "CUSTOMER" entity is a better suit. A customer that is staying in a room is a guest. Also, entities/tables should have singular names. EDIT: There's absolutelly no problem in what you call ...


4

Why do you need a triple reference? The savoy is a HOTEL. "Turkish massage" is a SERVICE. If the Savoy offers that, that's an entry ii your H_S table. If someone stays at the savoy, that's an entry in the BOOKING table pointing to the hotel; if they order a massage as well, that's an entry in the B_S table pointing to the booking and to the service. ...


2

Usually a 'secondary index' is an index which is not used to enforce the primary key constraint. This seems to be a pretty widely-accepted term in the world of relational DBMSes. In non-relational world, I don't know.



Top 50 recent answers are included