database-design

问题 This might be a silly question, but here goes: Is there a standard or best practice, which specifies in what order the foreign key columns in a table should? I for one like the idea of the PK being the very first column in the table, followed by all the foreign keys, and then the columns thats relevant to that table.. Other way of doing it is having the PK as the very first column, then all the supporting columns, and then all foreign keys... I guess it really doesn't matter, but I would like

问题 I have a small database that is used to track parts. for the sake of this example the table looks like this: PartID (PK), int PartNumber , Varchar(50), Unique Description , Varchar(255) I have a requirement to define that certain parts are classified as similar to each other. To do this I have setup a second table that looks like this: PartID , (PK), int SecondPartID , (PK), int ReasonForSimilarity , Varchar(255) Then a many-to-many relationship has been setup between the two tables. The

问题 How many fields are OK to have in a MySQL table? I have a form to get information from users, it is divided into 6 or 7 unites, but all related to each other. They are about 100 fields. Do you recommend to keep all of them in one table? Thank you all for your responses,well my table's data are about some personal information of users,all the work that is needed to be done is to get them from the user,save and show them and have the edit option. should i use the normalization? doesn't it

问题 An application I inherited tracks lab test results performed on material samples. Data is stored in a single table (tblSampleData) with a primary key of SampleID and 235 columns representing potential test results. The problem is that only a few tests are performed per sample, so each row contains over 200 nulls. Actually, there is a second similar table (tblSampleData2) with another 215 primarily null columns and a primary key of SampleID. The two tables have a one-to-one relationship and

问题 I'm creating a new table in SQL Server 2005 that needs 2 fields: DateTime and MyValue (Int32). The DateTime field will be unique so I will be setting a unique constraint on it. Which table structure is better and why? MyIndex (PK, int) MyDate (datetime) (IX_UniqueKey) MyValue (int) or MyDate (PK, datetime) MyValue (int) My feeling is that I don't want an artificial PK (MyIndex) in this table because it is unnecessary and because the dates will be unique I will use them to access any record.

问题 I am currently working on a system that involves storing multiple studies and details of their contents (A study can typically contain 1 < X < ~2000 images). My colleagues and I were discussing what might be the best method of storing files sizes (specifically the image sizes) in a database would be. The file sizes typically range from < 1kB to > 20MB. We are currently debating between storing the images sizes as: # of kilobytes (as an integer value) # of bytes (as a large integer value) # of

问题 I'm working with an old sql server 2000 database, mixing some of it's information with a new app I'm building. I noticed some of the primary keys in several of the tables are floats rather than any type of ints. They aren't foreign keys and are all unique. I can't think of any reason that anyone would want to make their unique primary key IDs floats, but I'm not a SQL expert by any means. So I guess what I'm asking is does whoever designed this fairly extensive database know something I don't

问题 I have this data that I need to put into 3rd and 4th Normal Form. I understand the basics of normal form but I'm confused with 3rd and 4th normal form and I've checked online but still don't understand. I'm creating a database which is being used by my system. 回答1: A relation in 4NF is also in BCNF, 3NF and the lower NFs. From this answer: A superkey is a set of columns that uniquely identifies rows. A candidate key is a set of columns that uniquely identifies rows and that contains no

问题 [ 1 ], [ 2 ] and many other references gives conclusion that BLOBs with size less tha 0.3-1 MB should be stored in database while BLOBs larger than 1 MB - in file system (possibly through FILESTREAM). FACEBOOK.com stores 6.5 (30 with thumbnails and size versions) billions pictures in files system [ 3 ]. Randal's white paper [ 2 ] reasons it by: Well, this does not convince me about necessity to store blobs in database but just about the fact that they should not be accessed/streamed

问题 I'd like to know a proper way to implement my situation here in ruby on rails 4.0. Lets say I have 2 models named House and Order . My Order table should have two columns from and to both referencing a house model. What should my relations between these two models be in this case? Note: I do not require any reference to order model from house model. I would like to have something like this in my Order table t.references :house, as:from (this should create a column named from and should be of