database-design

问题 I am already excited about document databases and especially about CouchDB's simplicity. But I have a hard time understanding if such databases are a viable option for multi user systems. Since those systems require some kind of relations between records which document databases do not provide. Is it completely the wrong tool for such cases? Or some tagging and temporary views are the way to accomplish this? Or else... UPDATE: I understand the answers so far. But let me rephrase the question

问题 I understand that the FirstName LastName "problem" is a frequent complaint of people who use websites designed by Americans. What do you think is a better system that will suit more countries? What fields would you recommend using to store the various ways that a name might need to be accessed, understood, or displayed? Depending on what the system is for I would propose the following fields based on the US idea of FirstName MiddleName and LastName. Middle names are almost unused in the US

问题 I'm still learning my lessons about data modeling in bigtable/nosql and would appreciate some feedback. Would it be fair to say that I should avoid parent->child relationships in my data modeling if I frequently need to deal with the children in aggregate across parents? As an example, let's say I'm building a blog that will be contributed to by a number of authors, and each other has posts, and each post has tags. So I could potentially set up something like this: class Author(db.Model):

问题 What should I set for Collation when creating tables in MySQL: latin1_swedish_ci or utf8_general_ci What is Collation anyway? I have been using latin1_swedish_ci , would it cause any problems? 回答1: Whatever you do, don't try to use the default swedish_ci collation with utf8 (instead of latin) in mysql, or you'll get an error. Collations must be paired with the right charset to work. This SQL will fail because of the mismatch in charset and collation: CREATE TABLE IF NOT EXISTS `db`.`events

问题 I am writing a Django application that has a model for People, and I have hit a snag. I am assigning Role objects to people using a Many-To-Many relationship - where Roles have a name and a weight. I wish to order my list of people by their heaviest role's weight. If I do People.objects.order_by('-roles__weight'), then I get duplicates when people have multiple roles assigned to them. My initial idea was to add a denormalized field called heaviest-role-weight - and sort by that. This could

问题 Looking for a scalable, flexible and fast database design for 'Build your own form' style website - e.g Wufoo. Rules: User has only 1 Form they can build User can create their own fields or choose from 'standard' fields User's 1 Form has as many fields as the user wants Values can be the sibling of another value E.g A photo value could have name, location, width, height as sibling values Special Rules: User can submit their form a maximum of 5 times a day Value's Date is important Flexibility

问题 I have a table called categories. The table holds categories and their sub(subsub)categories... Its an easy table: id parent_id title This way I can make categories with endless depth... I kinda hoped that cakephp would understand parent_id (I also tried category_id, but that makes cakePHP join on itself :D ) What is the right way to tackle this? NOTE: There is also a 'many to many' table called places. Those places can belong to one or more categories. 回答1: Tree behaviour is overkill for

问题 What would be the best way of designing a database to store blog posts and comments? I am currently thinking one table for posts, and another for comments, each with a post ID. It seems to me, however, trawling through a large table of comments to find those for the relevant post would be expensive, and would be done every time a blog post is loaded (perhaps with some amount of caching). Is there a better way? 回答1: It seems to me, however, trawling through a large table of comments All the

问题 My website has a followers/following system (like Twitter's). My dilemma is creating the database structure to handle who's following who. What I came up with was creating a table like this: id | user_id | followers | following 1 | 20 | 23,58,84 | 11,156,27 2 | 21 | 72,35,14 | 6,98,44,12 ... | ... | ... | ... Basically, I was thinking that each user would have a row with columns for their followers and the users they're following. The followers and people they're following would have their

问题 According to Five Simple Database Design Errors You Should Avoid by Anith Sen, using a common-lookup table to store the possible statuses for an entity is a common mistake. Edit + Answer: The figures in Anith's article aren't well labelled - I thought both Figure 1 and Figure 2 are examples of bad design , whereas Figure 2 is good design . Phew , got worried there for a moment. In summary: Lookup tables: good . Common-lookup tables: bad . I'll keep my question below for reference. The