On Sat, 23 Apr 2016 14:50:45 -0400 "Keith Medcalf" <kmedcalf at dessus.com> wrote: > > On Sat, 23 Apr 2016 08:56:14 -0400 > > "Keith Medcalf" <kmedcalf at dessus.com> wrote: > > > > > Those things that those other DBMSes do are holdovers to maintain > > > backwards compatibility with the good old days when dinosaurs > > > ruled the earth > > > As amusing as your rant is, it's not accurate. Treating columns as > > types is a "holdover" from mathematics and logic. It has nothing > > to do with maintaining backwards compatibility, or the cost of > > RAM. > > The specification of "Length/precision" as well as the use of > "varchar", "varbinary" and the like are holdovers from the days when > files had to have fixed record lengths so BDAM would work.
They might have originated in that way on System R. Ingres was developed contemporaneously on Unix, which then and now had no record-based file types. As I pointed out, > > Many new DBMS engines have been written in recent years > > (notably columnar stores) and, of those that support SQL, none > > abandoned strict column types. > (contrary to common mis-belief, varchar(100) does not mean a > "variable length character field with a length up to 100 characters", SQL does *not* define implementation. It defines semantics: user provides X, system replies Y. It makes no statement about how a column is stored. You know that, surely. Why paint yourself into a corner with an argument you know is lost before it begins? I guess I should remind you that length-limited character strings have lots of utilty irrespective of storage concerns. Some strings *are* fixed length, for example cusip, ssn, drivers licence, employee id, phone number. Length-checking is a simple aspect of validation. There are also more banal concerns about external representation. An address might be limited to 60 characters so that it fits in the billing envelope window. Maybe 60 characters is arbitrary, but we both know that 6000 characters will be too many. Length limits help keep the ruby on the rails. > In order for Codd and Date to conceive of a world wherein duck-typing > existed, a duck-typed language would have to exist first. Since such > was inconceivable before its invention, it is no wonder that it never > occurred to anyone that a database column could be ducky too. You are seriously underestimating them. You're misinterpreting the meaning and purpose of column types. Your rant about VSAM is, as physicists sometimes say, not even wrong. If the theory seems abstruse, you also utterly ignore observed detrimental effects of the lack of type enforcement, namely the complexity that arises at SELECT time, when the application has to cope with whatever detritus got parked in the database. On a SQLite scale, many times that's not a problem because writers are highly constrained. But in general it's a central concern, and was one of the motivations for the invention of the relational model. --jkl
