Re: Typeless Relational Database

If you access your (SQL/relational/typed) database with DBI/DBD, you really get (sort of) a typeless database.

Read a record with a "string" field containing only figures, put it in a scalar, multiply it by something, store it again in the scalar and save it in the database: the data start as a string, gets silently converted to an integer or float (as need be) and gets saved as a string again. Perl has taken care of all type-conversions.

So what are we complaining about? The small effort of setting-up the database? I actually find that a Good Thing^tm as it makes you think about your data, but YMMV.

And if you want to skip even that little effort, declare all your fields to be 'VARCHAR' (max. length 255) or 'TEXT' (max. length 65,535) in MySQL.

One single type to rule them all and in the database bind them! Looks pretty (and) typeless to me.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Comment on Re: Typeless Relational Database Select or Download Code

Replies are listed 'Best First'.
Re^2: Typeless Relational Database by jhourcle (Prior) on Jul 01, 2005 at 11:52 UTC
Yes, it'll work... and if you use it for any extended period of time, you'll most likely never use it again. (and prove that strict typing can be a good thing) I've had to deal with tables where someone had dne this -- every field was a varchar(255), completely denormalized. (it was basically just logging information from sitescope). I ran into the following problems: Any sort of selects were slow.-- Every field was larger than it had to be (strings for dates, strings for numbers, etc.) as it could read fewer records per disk access Because the fields weren't fixed length, anything with a 'where' clause couldn't just know that field 6 started at byte 24 ... it'd have to look through fields 1-5. Inequality matches were abysmal. SQL doesn't have seperate 'lt' and '<' operators, so you had to do the conversions by hand...and you'd have to parse all of the date strings every time. No sanity checking on values -- because you could write anything into any field, you can't catch bad data on insert -- you find the problems when you go to read. There were probably other problems, that I either never found, or have managed to block out from that horrible time. Yes, this allows you to start collecting data with little thought, but it makes it a pain to deal with the data in the future -- it's like saving any type of file to a folder, without any markings if it's an image, text file, or some other format -- writing is just fine, but it's much more work when you have to go to actually read them. It was so horrible to deal with, and as I couldn't change the application that was writing, I found it easiest to move the data from the bad table to something more compact, with typing. So, to anyone who thinks strict typing is a problem -- try this, as an experiment. If it works for you, fine. If it doesn't, well, then get rid of it as quickly as possible.	[reply]

Replies are listed 'Best First'.

Re^2: Typeless Relational Database
by jhourcle (Prior) on Jul 01, 2005 at 11:52 UTC

Yes, it'll work... and if you use it for any extended period of time, you'll most likely never use it again. (and prove that strict typing can be a good thing)

I've had to deal with tables where someone had dne this -- every field was a varchar(255), completely denormalized. (it was basically just logging information from sitescope).

I ran into the following problems:

Any sort of selects were slow.-- Every field was larger than it had to be (strings for dates, strings for numbers, etc.) as it could read fewer records per disk access
Because the fields weren't fixed length, anything with a 'where' clause couldn't just know that field 6 started at byte 24 ... it'd have to look through fields 1-5.
Inequality matches were abysmal. SQL doesn't have seperate 'lt' and '<' operators, so you had to do the conversions by hand...and you'd have to parse all of the date strings every time.
No sanity checking on values -- because you could write anything into any field, you can't catch bad data on insert -- you find the problems when you go to read.

There were probably other problems, that I either never found, or have managed to block out from that horrible time. Yes, this allows you to start collecting data with little thought, but it makes it a pain to deal with the data in the future -- it's like saving any type of file to a folder, without any markings if it's an image, text file, or some other format -- writing is just fine, but it's much more work when you have to go to actually read them.

It was so horrible to deal with, and as I couldn't change the application that was writing, I found it easiest to move the data from the bad table to something more compact, with typing.

So, to anyone who thinks strict typing is a problem -- try this, as an experiment. If it works for you, fine. If it doesn't, well, then get rid of it as quickly as possible.

[reply]