问题
I have got a table structure which is as follows:
`CREATE TABLE "pages" (
"id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
"title" varchar(255),
"body" varchar(255),
"author" varchar(255),
"email" varchar(255),
"reference" varchar(255),
"created_at" datetime,
"updated_at" datetime);`
Is this table structure bad?
edit-1
Its sqlite database i am using.
回答1:
Based on the limited info that you have provided. If the table fits your needs then no it is not bad.
However if you will have the same author with multiple entries. You might want to consider removing the author from your pages table and have a separate table for authors then use a foreign key relationship between authors and pages.
You could do the same thing with the email if you will have multiple emails for each author.
回答2:
If its failing it might be due to the space between "v" and "archar" on the 2nd line? Although that might just be a cut/paste error.
回答3:
You haven't given us much to go on. But if your project has a technical lead who expects you to meet certain structural standards, there should be a book, paper, file, or web page that tells you what's expected of you.
The only column that's not nullable is the meaningless id number. That's almost certainly a problem. I don't know what all the column names mean, but I doubt that any of them should be nullable.
All the varchar() columns are the same length. That's probably not what you want.
I'm going to guess that "pages" refers to web pages. If that's the case, you probably want "title" to be unique. (And you probably want it to be less than 255 characters.)
If "email" means the current email address of "author", then there's a transitive dependency between "author" and "email". (It's not yet in 3NF.) If "email" means the email address of "author" at the time of publication, there's probably a multi-valued dependency between "author" and "email". (So it's not yet in 4NF.)
You probaby don't want the email address to allow 255 characters either.
The columns "created_at" and "updated_at" are about the row, not about the "page". I prefer to keep data about the row in a separate table; that will reduce the size of the real data, narrow the table, allow more rows per page, and increase speed.
来源:https://stackoverflow.com/questions/9213535/what-is-bad-in-this-table-schema-structure