On Wed, Dec 28, 2005 at 11:35:11AM -0800, Tom M. wrote:
Hello Radek.
Your question has been asked and answered a number of times.
Not exactly. Many times was answered a question I do not ask.
Spend some time learning Rails. Understand one thing up front: Rails
is OPINIONATED. It doesn’t work the way that YOU want it to, it works
the way that David wants it to.
Yes I’m trying to learn.
Many people (and growing exponentially it seems) agree with the way
that David wants it to work. Some will never agree with him, which
isn’t a good or a bad thing, it’s just a fact.
I do not want talk things, I can’t change. It’s waste of time.
David wants your DB structure to follow certain rules. Synthetic
primary keys are one of the rules. If you force Rails (which is likely
possible) to conform to your way of thinking, you’re going to find
that you don’t like Rails much because you don’t understand it very
well.
I underestand synthetic keys where’s none. But forcing it everywhere
makes me completly lost. I’m desoriented, its just only pain. Yes,
I’ll try to to change my mind, and change my tools.
When I first started, I immediately decided that I didn’t like David’s
pluralization scheme. After all, I had designed many databases and had
heartfelt beliefs about how they should be designed. Pluralization was
not one of those beliefs. In my case, I agreed wholeheartedly from past
experience that natural keys are horrible primary keys, so I had a leg
up on you on that one.
Pluralization is another things which hit me first on the begining. I
do not want talk about it. I just write one sentence I think the last
time I was thinking about pluralization. “You should know English,
unfortunately some unknown dialect of English”.
I designed the DB my way, and forced Rails to use the ID columns of
my creation, and table names of my creation. But after a week, I
realized I was struggling with details that nobody else was dealing
with, and my code didn’t read as fluently as the Rails code that
everyone else was posting to this list. The code that followed David’s
rules read like English, my code read like traditional computer code,
very unnatural…so I just threw in the towel and started over,
following the rules.
Only one word, I know better computer code than English. If the
programming langue will be English, I’ll be out of work.
In no time I was convinced it was the right decision.
In my opinion, you need to:
-
Throw in the towel on your DB design and go with the flow. Give it
a few days, and see if you like it. If you don’t like it, use
another framework.
-
Give up now and use another framework.
I promis I’ll do it. I’ll do it both ways. Simultaneously.
What you said about adding complexity to suit Rails is true to an
extent. You have a natural primary key and you “shouldn’t” need
another synthetic one. However, if you manage to force Rails to
work with your schema, you will be adding far more complexity in
your code to handle the special case than you would add to the DB
schema by following David’s and Rails’ assumptions.
I need to know where the border of the complexity in Rails is. What
and what not leads to it. I’m not looking or one size fits all
system. I just need to know for what size which system fits.
Question: How do you handle the natural keys. It does not matter, if
there are some synthetic keys or not, It doesn matter if the
application works or not if there are duplicity in natural keys.
Question: How do you handle constraints. Especially if some other
application will access the data.
P.S. It’s more important to know what you can’t do then what you can.
Because if you know what you can’t do it’s waste of time try to do it.
P.S. Thanks for explanation.
No matter how far down the wrong road you’ve gone, turn back.
Turkish proverb
… so turn back … Now!