Tag Info

New answers tagged

2

It seems that you are involved in a scenario that requires the creation of an auditable database. You may find related information by searching for the terms temporal databases and database history tables. Yes, there are cases in which it is paramount to keep track of the updates that an entity suffers over time, and there are other cases in which changes ...


4

If I understood you correctly, you have two sorts of entities to manage: Players (human beings that participate in your game) Characters (fictional entities that the players use/manipulate in your game) Once you look at your problem like that, you could model it easily like this: players table, with a player_id as PK and information about your real ...


1

When modeling the data, consider only the data you have or expect to get: "We have customers most of whom will have only 1 or 2 deliveries per week with most deliveries having 5-10 different items." create table Customers( ID int not null auto_increment, -- PK ... ); create table Deliveries( ID int not null auto_increment, -- PK CustID ...


1

Properly normalized it will have 3 tables as follows: Kid kid_id (pk) classroom_id (fk to Classroom) Teacher teacher_id (pk) name Classroom classroom_id (pk) teacher_id (fk to teacher) This way you have no duplication and no update anomalies.


0

I will be using MS SQL terms below but you can translate them into the DBMS that you will be using. I also made some assumptions that seemed logical, so you can drop those if they do not fit your model. I would setup the tables in the following manner: Person Table PersonID int PK FName Varchar(50) LName varchar(50) DoB Date FK Name Table Name ...


0

From your explanation, I would assume this is a summary of some other data source / table. As you are providing this in a browser; response time is the essence. So create a table with your 31 cols. This is not a proper solution but it does work as a fast 'cache' to your web-app. You do have to ensure that your summary tables are in sync with the actual ...


4

It depends on what you are going to do with the data, as it always does. It's usually dangerous to assume that the data is never going to be used in some other way. Your question illustrates this nicely. The original design of "summaries" assumed that weekly summarization would always be the intended use, and now you want daily summarization. The ...


1

I think table with lots of rows, in this case, can have several benefit: You will have columns with a data. Not columns where you give them a meaning. You can eventually make partitions on this data, depending from your rdbms, with range partition, for example You can scale aggregate data. For example you can keep existing table as aggregation of new ...


0

SQL is very poor at manipulating/analysing and extracting information from your comma type schema. That schema is also a breach of Codd's rules Rule 2: The guaranteed access rule: All data must be accessible. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the ...


2

I won't put all of them together. Even if you query them together, it may occur that your application will be able to post multiple images per post or multiple events per post or multiple posts per event. In this case you would be able to save space. The JSON may be a good idea, but it would be better (in view of indices) to use multiple tables. This way ...


1

A couple of cmments: CommentReplies seems to be implementing many-to-many. I would expect it to be one-to-many -- as in, each comment has one 'parent'. One-to-many does not need an extra table; you simply have parent_id as a column in Comments. Consider using ENUM datatype instead of adding a XxTypes table.


0

You should have a table for each class of thing you want to offer a discount on. From your question that would be a table each for products, customers and stores. Most likely you will have these tables in your design already. Each will have a column of an appropriate type to hold the discount. You don't say what you will offer but a percentage discount ...


2

Your Question is much too broad to provide any specific table design suggestions. Just this, "Which one has Employee", could many any of dozens of things as mentioned in the Answer by Neil McGuigan: Person who first took customer inquiry phone call, the sales person who responded, the sales assistant who filled out Sales Order, the production manager who ...


2

Price shouldn't be in your order table. A sales order hasMany line items. Price belongs to line item. As does delivery date. An invoice is a request for payment. An order can have many (or no) invoices, and an invoice can be for many orders. It's a many to many relationship. You don't really need invoices if you're doing pay-before-delivery (or don't do ...


1

This schema would make sense to me: tblCompany ( Company_ID PK Company_Name ) tblProduct ( Prod_No PK Company_ID FK_tblCompany_CompanyID Prod_Name Prod_Mark_No Prod_Catalogue Prod_Type Prod_Expiry_Date Prod_Verify_Date Prod_Comments ) You could have separate tables for product type and product catalogue to get to 3NF but that's a ...



Top 50 recent answers are included