Marnen Laibow-Koser wrote:
Will Merrell wrote:
Marnen Laibow-Koser wrote:
That shouldn't be a problem. Broadly speaking, it is better to refactor
a database tomorrow than to overdesign it today.
I'm certainly not in favor of over design, which is why I suggested
something
Kristian - thanks for the reply. I think it would be easier, too! But...
I was wondering if I am violating some kind of best practice to put all
the fields in one model even if half of them will be empty most of the
time?
--
Posted via http://www.ruby-forum.com/.
--
You received this message
Taylor Strait wrote:
Kristian - thanks for the reply. I think it would be easier, too! But...
I was wondering if I am violating some kind of best practice to put all
the fields in one model even if half of them will be empty most of the
time?
i think it can sometimes be a fault to
I would look into understanding how to normalize your databases.
http://databases.about.com/od/specificproducts/a/normalization.htm
The problems I have personally experienced with normalizing a database
is that oftentimes you can over-normalize a database to the point that
it creates havoc on
Taylor Strait wrote:
Kristian - thanks for the reply. I think it would be easier, too! But...
I was wondering if I am violating some kind of best practice to put all
the fields in one model even if half of them will be empty most of the
time?
They won't be empty; they'll be false. Big
You could also check up document oriented and schema free databases
like couchdb and mongodb if you would like to see your design problem
from another perspective.
Good luck,
Kristian
2010/1/25 Alpha Blue li...@ruby-forum.com:
I would look into understanding how to normalize your databases.
Will Merrell wrote:
Marnen Laibow-Koser wrote:
You're right that option A is pretty much a bad idea. I can't tell you
how much time I have spent refactoring databases that were *guaranteed*
never to change.
That shouldn't be a problem. Broadly speaking, it is better to refactor
a
7 matches
Mail list logo
