Structured (or Standard) Query Language
Most databases nowadays offer an SQL interface, and some offer nothing else. In theory, given the same table names and relationships, an SQL query should produce similar results no matter what database it is actually accessing.
But that's all SQL is: a way to add or extract data. The underlying database might not even really be relational: for example, the Filepro database that many of us used on SCO Unix systems (and Tandy before that) is not strictly relational, but it does have an SQL interface available.
I am often surprised to see people using databases where they aren't needed. For example, I recently had a conversation about maintaining a "database" of approximately 400 items. The client asked if he'd need Microsoft SQL Server. Well, no, for 400 records a flat file and a Perl script are fine. I might use a Perl .db file for convenience if no one needs the text for any other reason, but we certainly don't need a SQL database. If he had SQL programmers or needed to write custom reports that might be different, but this was just a very simple task, so I explained that we didn't need it. He countered with a statement that he wanted to "have room to grow". I explained that even ten times that number of records still wouldn't require SQL server, but I don't think he believed it. In fact, given the amount of memory available in modern machines and the overhead of "real" databases, the Perl script would probably be faster until we got up to many tens of thousand records (obviously dependent on record size and access needs).
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-07-06 Tony Lawrence
On two occasions, I have been asked [by members of Parliament], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"...I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. (Charles Babbage)