Databases Have To Be Persistent

Myth. Common 'NimbleDatabases' run primarily in memory and are only persistent if you insist. Persistence (or its availability) is, however, a very useful feature for databases. (Similarly, all of the ACID and transactional properties are optional.)

EditHint: merge with DatabasesAreMoreThanJustStorage

I disagree with merging with DatabasesAreMoreThanJustStorage, because the argument there is that more bussiness logic should be "inside" databases, and the argument here is that more database funcionality (RelationalOperations? for example) should be usable outside of the database... lets get the database into the client business logic, not the bussines logic into the database (That is not rule, but I believe RelationalWeenies have been trying to make people do more things inside stored procedures for years... and they should be trying to do the opposite, to have more relational power outside of the database)

Well, some see stored procedures as application logic also. The distinction is a bit fuzzy. We need to clarify the difference. Stored procedures tend to have a "glass house" or BigIron reputation. The languages of SP's are also a bit long-in-the-tooth.

'The idea behind stored procedures is to place all data consistency logic as close to the data store as possible and to have it be reusable resource so that the same logic need not be coded in multiple locations. This makes a good deal of sense when your data is driving several hundred applications on several thousand workstations. '

Re The languages of SP's are also a bit long-in-the-tooth.

'Java ( Oracle ) may not be new, but long in the tooth is overstating it and some implementations (DB2 on zOS) allow any language to be used.'

Maybe the name of this page should be RelationalOperationsAreMoreThantJustDatabases? ?

Note that a database doesn't have to support stored procedures to be a database.

Or perhaps TheRelationalAlgerbraIsAboutRelations? ?

A database is a persistence engine. A query engine can be relational algebra, or set theory or predicate calculus or full text search via regex .... .

I disagree with this terminology assessment, but invite you to describe where you derive your conclusion from.

It is not an Assessment. You are at liberty to disagree. You can not use LINQ (MicrosoftLinq) on a array if you do.

LINQ (MicrosoftLinq) has a foot in database-land. I don't believe definitions have to return Boolean to be useful.

So it is not possible to usefully distinguish query and searching from storage because most query tools have 'a foot in database-land'. Can you write a query tool that searches a stream of on demand data like a stock market ticker feed. Is such a feed a database? If so would it be one if it were not searched. Is it your claim that if you can search it must be a database and not otherwise? Can a datastore exist which does not have its own query tool? Can you bolt one on? If so how does it become a database if you do so? How about transactions are they relevant? Do you think that the actually theory of RDMS design may make such distinctions? Would matter if it did?

--Bottom

Let's look at my working definition: A database management system (DBMS) is a collection and attribute management tool that standardizes or centralizes common attribute- and collection-processing and management idioms in an efficient and scalable manner.

The more attribute- and collection- processing and management idioms it "covers", the more "databasish" it is. We could add a threshold mechanisms similar to what I did with DefinitionOfLife to make it Boolean, but that may be over-engineering it. I wouldn't make "storage" a prerequisite factor because RAM-ifying an existing DB for speed does not necessarily change the overall usage patterns of a given RDBMS. They may serialize and disk-ify it at night for backup purposes. I'm sure ideally those who set up the a RAM-DB would prefer it disk-ify automatically, but when forced between the decision of speed versus disk, they may choose to go with speed. -t

Ok if you say so. But what makes you think a database is alive? Or more precisely what makes you think Ram is not storage, and if it is then why can't you have a database that purges all its data every 30 seconds and thus makes retrival even faster. For that matter why isn't a variable a database? Or maybe a register very fast you know.

TenSeven. -- Bottom

The reference to DefinitionOfLife was in regard to the construction of definitions, not about life itself. RAM indeed is "storage". The duration is all relative. There is a topic on the definition of "persistence" around here somewhere that raised related issues. As far as your 30-second deletion example, I'm not sure what you are trying to get at. Should I add, "and not be poorly designed" to my definition? That should go without saying. Permanent storage of useless garbage does not make something a DB either. Databases don't by themselves prevent GIGO. It's a tool, and if you want to stick the tool into your eye instead of make something useful with it, it's still a tool. -t