database-design

问题 I have two databases with the same structure. The tables have an integer as a primary key as used in Rails. If I have a patients table, I will have one patient using primary key 123 in one database and another patient using the same primary key in the other database. What would you suggest for merging the data from both databases? 回答1: Set both your databases up with entries in config/database.yml, then generate a new migration. Use ActiveRecord::Base.establish_connection to switch between

问题 Hi I'm developing an invoicing application. So the general idea is to have two tables: Invoice (ID, Date, CustomerAddress, CustomerState, CustomerCountry, VAT, Total); InvoiceLine (Invoice_ID, ID, Concept, Units, PricePerUnit, Total); As you can see this basic design leads to a lot of repetiton of records where the client will have the same addrres, state and country. So the alternative is to have an address table and then make a relationship Address<-Invoice. However I think that an invoice

问题 Suppose the following data schema: Usage ====== client_id resource type amount Billing ====== client_id usage_resource usage_type rate In this example, suppose I have multiple resources, each of which can be used in many ways. For example, one resource is a widget . Widgets can be foo ed and they can be bar ed. Gizmo s can also be foo ed and bar ed. These usage types are billed at different rates, possibly even different rates for different clients. Each occurence of a usage (of a resource)

问题 I am designing a database which will be used for internationalized content. One of the features is a tagging system, similar to what Stack Overflow has. This is what I've got: TABLE tags tag_id | int(11) unsigned | NOT NULL | PRI | auto_increment TABLE tag_translations | tag_translation_id | int(11) unsigned | NOT NULL | PRI | auto_increment | fk_language_id | int(11) unsigned | NOT NULL | MUL | | fk_tag_id | int(11) unsigned | NOT NULL | MUL | | tag_name | varchar(255) | NOT NULL | UNI |

问题 What are the disadvantages of using GUIDs? Why not always use them by default? 回答1: Integers join a lot faster, for one. This is especially important when dealing with millions of rows. For two, GUIDs take up more space than integers do. Again, very important when dealing with millions of rows. For three, GUIDs sometimes take different formats that can cause hiccups in applications, etc. An integer is an integer, through and through. A more in depth look can be found here, and on Jeff's blog.

问题 What is the more efficient (in terms of query performance) database table design - long or wide? I.e., this id size price 1 S 12.4 1 M 23.1 1 L 33.3 2 S 3.3 2 M 5.3 2 L 11.0 versus this id S M L 1 12.4 23.1 33.3 2 3.3 5.3 11.0 Generally (I reckon) it comes down to the comparison of performance between GROUP BY and selecting the columns directly: SELECT AVG(price) FROM table GROUP BY size or SELECT AVG(S), AVG(M), AVG(L) FROM table Second one is a bit longer to write (in terms of many columns)

问题 In my application I've got "articles" (similar to posts/tweets/articles) that are tagged with descriptive predefined tags: i.e "difficult", "easy", "red", "blue", "business" etc These available tags are stored in a table, call it "tags" that contains all available tags. Each article can be tagged with multiple tags, editable through a custom admin interface. It could be tempting to simply bundle the tags for each entity into a stringified array of the IDs of each tag and store it alongside

问题 Currently my users table has the below fields Username Password Name Surname City Address Country Region TelNo MobNo Email MembershipExpiry NoOfMembers DOB Gender Blocked UserAttempts BlockTime Disabled I'm not sure if I should put the address fields in another table. I have heard that I will be breaking 3NF if I don't although I can't understand why. Can someone please explain? 回答1: There are several points that are definitely not 3NF; and some questionable ones in addition: Could there

问题 When retrieving entries in a database, is there a difference between storing values as a float or decimal vs. an int when using ORDERBY in a SELECT statement? 回答1: It depends. You didn't specify the RDBMS so I can only speak to SQL Server specifically but data types have different storage costs associated with them. Ints range from 1 to 8 bytes, Decimals are 5-17 and floats are 4 to 8 bytes. The RDBMS will need to read data pages off disk to find your data (worst case) and they can only fit

问题 I'm designing a new web project and, after studying some options aiming scalability, I came up with two database solutions: Local SQLite files carefully designed for a scalable fashion (one new database file for each X users, as writes will depend on user content, with no cross-user data dependence); Remote MongoDB server (like Mongolab), as my host server doesn't serve MongoDB. I don't trust MySQL server at current shared host, as it cames down very frequently (and I had problems with MySQL