I posted to the Sequel Google Group but it’s horribly slow, assuming it
took
my post.
Does anyone on here know if it is possible to create a non-integer
primary
key in Sequel? If so how? Also help with creating a non integer
foreign
key would be great too. I’ve done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or
AUTOINCREMENT.
Thanks,
Glen
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
I posted to the Sequel Google Group but it’s horribly slow, assuming it took
my post.
Does anyone on here know if it is possible to create a non-integer primary
key in Sequel? If so how? Also help with creating a non integer foreign
key would be great too. I’ve done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or AUTOINCREMENT.
The docs seem to indicate that you can use arbitrary PK’s:
On Tue, Jun 24, 2008 at 11:03 AM, Robert K. [email protected]
wrote:
robert
Thanks for the input Robert.
It turns out there is a rather vaguely documented :auto_increment =>
false
that needed to be included in my primary_key definition. Now I just
need to
figure out how to get foreign_keys to work. The sequel-talk group seems
to
be working so I will continue this pursuit there.
Thanks again.
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
It turns out there is a rather vaguely documented :auto_increment => false
that needed to be included in my primary_key definition. Now I just need to
figure out how to get foreign_keys to work.
I have seen this documented in the docs. Does it not work as
advertised?
The sequel-talk group seems to
be working so I will continue this pursuit there.
Good chances that you get more profound feedback there.
key in Sequel? If so how? Also help with creating a non integer foreign
be working so I will continue this pursuit there.
Thanks again.
–
“Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can’t hear a word you’re saying.”
-Greg Graffin (Bad Religion)
I don’t want to hijack this thread, and people may be mad about me
saying this again. Will you (that would be people in general and
doesn’t include Greg as far as I can see) please stop using
auto_increment as a guarantee of uniqueness in a database/set?! The
set theory should be handled in the db anyway, IMHO.
It’s convenient, but think, for example, if you move a postresql db
schema to oracle, or vice versa, or even worse to SQLite (nothing
against you guys, I think you have a really cool product and am
looking forward to future updates). Anyways, “Uh-oh.” “Price is
Right” … buy another key so we can move on. Silly. This is how
mud/clay is added to structures because people think they are being
practical engineers.
Ruby is good stuff. Let’s use it in a good way! Likewise, the
databases need to be used correctly.
Does anyone on here know if it is possible to create a non-integer
primary
key in Sequel?
If you mean a floating-point primary key, that doesn’t sound like a good
idea, for the same reason that doing == comparisons with floats isn’t a
good idea.
No, I was looking to do more what Todd was talking about. I’ve never
seen
any reason to generate a pointless counter for a key and in analog extra
constraints when the DBMS handles it for you simply by working in sets
(and
in some cases bags). If my DB is a model of real world entities as it
should be then there should be a unique indentifier for said entities
which
means I shouldn’t have to number them just because.
In other words I am using necessary table elements as keys.
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
If my DB is a model of real world entities as it
should be then there should be a unique indentifier for said entities which
means I shouldn’t have to number them just because.
In other words I am using necessary table elements as keys.
The problem with “real world” unique identifiers is that even if they
stay uniqui they may change. The worst part it that they do change, even those you
though would
never ever possible change.
Surrogate keys do not have this problem. They may have other problems,
but it is worth it,
imho.
On Wed, Jun 25, 2008 at 12:12 PM, Rimantas L. [email protected]
wrote:
may change. The worst part it that they do change, even those you though
I’m curious as to when and why it matters if a primary key is mutable or
not. As long as it is still unique and any necessary side-effects are
handled either by the app or the DBMS.
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
I’m curious as to when and why it matters if a primary key is mutable or
not. As long as it is still unique and any necessary side-effects are
handled either by the app or the DBMS.
Well, the first time you have to handle those side effects in your
app you will see why it matters
On Tue, Jun 24, 2008 at 11:33 PM, Robert K. [email protected]
wrote:
I posted to the Sequel Google Group but it’s horribly slow, assuming it
You’re welcome.
It turns out there is a rather vaguely documented :auto_increment => false
that needed to be included in my primary_key definition. Now I just need
to
figure out how to get foreign_keys to work.
I have seen this documented in the docs. Does it not work as advertised?
I didn't run across it in my initial search. The pirmary_key
method
doc says to see column for available options. There is no
:auto_increment
listed in the valid options for column. It is logical that it would
exist
but I didn’t see it in the doc. At least it didn’t appear in a straight
forward manner.
The sequel-talk group seems to
be working so I will continue this pursuit there.
Good chances that you get more profound feedback there.
Turns out Jeremy was having to approve my messages to the Google
Group/list
which explains why it appeared to be acting oddly.
Cheers
robert
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
I’ve always believed it was more the role of the DBMS to handle such
things
anyway. Especially when you have data being accessed by multiple
applications.
–
“Hey brother Christian with your high and mighty errand, Your actions
speak
so loud, I can’t hear a word you’re saying.”
On Wed, Jun 25, 2008 at 1:12 PM, Rimantas L. [email protected]
wrote:
<…>
If my DB is a model of real world entities as it
should be then there should be a unique indentifier for said entities which
means I shouldn’t have to number them just because.
In other words I am using necessary table elements as keys.
The problem with “real world” unique identifiers is that even if they
stay uniqui they may change
You mean schema change, or something else?
The worst part it that they do change, even those you though would
never ever possible change.
Please clarify.
Surrogate keys do not have this problem. They may have other problems,
but it is worth it,
imho.
Regards,
Rimantas
That sounds more like a schema design problem than a programming one.
Of course, this debate will go on forever in db circles. Some swear
upon OO and other styles of dbs, even. I sort of side with Celko
(smart guy with a somewhat bearable cocky attitude that writes db
books and used to frequent – maybe still does –
comp.databases.theory) and personally like the RDBMS. Even though
Ruby is very OO, it does lend itself well to set theory. But, to each
his or her own.
There’s nothing wrong with surrogate keys, really. But the whole
arbitrary number defining a tuple’s existence and uniqueness doesn’t
move well across platforms. Not only that, having to define extra
UNIQUE constraints to make logical sense is redundant… This is one
of the reasons I tend to avoid using Rails simply because it’s not
simple to do what I want.
Taking care of such a thing in the app will not scale well. For
situations where you prefer convenience instead of data integrity or
all the unit tests you want to write to ensure that integrity, then I
guess it’s applicable.
I posted to the Sequel Google Group but it’s horribly slow, assuming it took
my post.
Does anyone on here know if it is possible to create a non-integer primary
key in Sequel? If so how? Also help with creating a non integer foreign
key would be great too. I’ve done some poking through the Rdoc and some
experimentation and it wants to make everything :integer or AUTOINCREMENT.
Thanks,
Glen
Hey Glen, can you give us an answer about whether primary key and
foreign key can be handled by the designer for certain databases with
Sequel? I’ll RTFM eventually, but was just curious if you found out.
