Database Verbs

{If you don't like the thread-mode nature of this topic, then plese fix it without deleting the whole damned topic again, please.}

Since I need to keep mentioning this concept over and over again, I decided to make a new topic in the spirit of OnceAndOnlyOnce.

DatabaseVerbs are TopMind's term...

{It is a topic name, not a "term"}

Now you're being unfair. These are in fact standard database operations that are never reimplemented. That point stands despite the fact that, yes, C/C++/Java/etc are Turing Complete and can be used to implement these and much more. I think the original phrasing "..are terms for typical database operations..." was completely fair. Possibly TopMind doesn't understand non-DB programming, but also possibly his detractors aren't steeped in DB paradigms. -- DougMerritt

Where in the computer science or software developer literature would one find reference to the standard definition of the term DatabaseVerbs? If TopMind is not coining a term, then it is part of the DB paradigm, so it must have an extensive background in the field which can be cited and discussed.

{Again, it is a topic name, not a "term". If you have a better name for the concept/topic, your suggestions are welcome.}

...for typical programming operations such as:

It could be argued that if you are doing these things explicitly, it isn't OOP, and that these actions fall into the category of 'procedural cop-outs' along with get and set. This view, however, requires a degree of ideological purity that would have been considered excessively fanatical by the Khmer Rouge. - JayOsako, still under the nefarious influence of the Holub article (http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html) mentioned in MvcIsNotObjectOriented.

These aren't exclusive to databases, so they aren't really "database verbs". They could just as easily be "file verbs" or "memory verbs".

Persistence Verbs [maybe. Create, Retrieve, Update, Delete are the 4 activies normally associated with RDBs, leading to the common acronym CRUD. Using CRUD rather than DatabaseVerbs is more likely to be clear to everyone, and has the advantage that it's shorter.]

Most associate it with GUI's or UI's. CRUD is a GUI concept. I am not talking about GUI's here, and CRUD does not directly imply cross-referencing and searching.

[SQL works well, too. Question: aren't all the operations beyond those 4 considered to be subparts of them? Wouldn't it be correct to say that Filter/Sort/Join really are just ways to parameterize the Retrieve operation?] I am not sure what conceptual purpose that would serve here.

DRAM is not persistent, so these aren't just "persistence verbs".

How about "state alteration verbs"?

CRUD is not exclusive to databases. You can perform all of those operations on files or memory. Perhaps ReadWriteStorageVerbs? is a better category for these words.

{Things like cross-referencing, filtering, aggregation, and sorting are not necessarily directly tied to storage (persistence).}

TopMind uses the phrase "database verbs" to accuse anyone who uses them outside a database of ReinventingTheDatabaseInApplication, as if only relational databases should be used to perform these behaviors.

This topic is to consolidate a repeated concept, not to accuse. The context of the claim is usually that OO tends to reinvent them in inconsistent ways; whereas, relational "encapsulates" them into a set of well-defined and well-understood rules. They become "atoms" that you can rely on to be the same rather than deal with inconsistent roll-your-own variations.

But OO doesn't "reinvent" these verbs. These verbs can be used to name similar behaviors in many different contexts. OO helps us implement those behaviors. Once implemented they become "atoms" that we rely on to "be the same". What you keep calling "roll-your-own" we call "programming". If a database (or library, or file system, or ORB, or whatever) already provides the implementation we need, we use that. We can't use a database to do things a database doesn't do.

Which would not include those in the above list, I assume. Rolling your own when you don't have to is not recommended, I would note.

{EditHint: perhaps some of this below should be moved to AreTablesGeneralPurposeStructures or WhenAreDatabasesNotAppropriate or DedicatedStructuresVersusRdbms. This current topic is more about interfaces than implementation.}

Quite often you do have to roll your own. That's why databases don't solve numerous problems that the weenies claim they can solve. They solve specific problems: customer accounts, web based forums, repetetive data.

What is an example of "non-repetative data" that wouldn't go well in a DB? I do wish there were dynamic relational implementations (see MultiParadigmDatabase) for a more flexible approach, such as reducing concerns about hard-wired column widths. But the static DB's are still usually better than roll-your-own alternatives even with their annoyances.

The reason people don't ship databases with 100KB programs for example, is because the database is just too big for the customer to justify. And it's also too hard to install too.

I grew up in the Era of Clipper and Delphi. It was quite easy to ship these with a database engine. Often there were ways to update the code separate from the database engine such that the app executable was relatively small. For example, a typical application may have had a 300k database + library section, and the app part was about 50k. This was important in the modem age. There was also an option to put it together into one big EXE. I think products went away from these when OOP became popular, but such products showed it could be done. I agree that existing products are weak. But this is not because of limited possibilities, but because of fads.

{I grew up in the late era of Delphi. Can you point me to some clipper pages? Are they still around? Sounds interesting. Personally, I have been looking for embedded database solutions so I can ship a database with the application and not worry about size/installation. Yes, I do want to ship even a small database with my application instead of using an ini file many times (despite my previous comment.. that was more playing devil's advocate). Especially when the ini file gets complicated and larger than originally intended. Or the ini file starts having multi dimensions (turn two ini files into one with a database.) Or where XML would normally be used to store data by an XML weenie, I'd hope to use an embedded database. But you don't hear about it these days? Because people just don't see the light? My view is that sometimes OO encourages laziness. "Oh, don't waste time integrating a database with the application, just make a few extra objects for all these data snippets and be done with it." I'd still like something even smaller and more shippable than firebird and SQL though.}

They don't solve that specific problem, unless they are rolled. So roll your own smaller database, maybe even based on the original. Some database weenies might go as far as thinking that even ini files are flawed, and that even ini files should be run as database instead.

When table browsers were as nimble as text editors back in the early 90's, I saw no problem with that. Again, it is a matter of what is popular, not what is possible.

{Yes that would be nice.. I agree. It would be lovely to have a common tool to edit small database files, instead of all this XML. Even some of the config files bother me, because you have to sift through all the comments just to get to one little setting. It could be organized in a mini-database instead with a "comment" column.}

If you resort to database communism, every program including Ed and the Clock on the taskbar will be run off a database. But the database wasn't programmed in database, it was programmed in a programming language. Keep in mind that you can't program a database with a database. But you can program a program with a program. Some of the thrill about programming is about the thrill of being able to program a database. But you can't database a program.

I don't see what this has to do with anything. Everything is 1's and 0's underneath. However, that does not imply that we should program directly in binary. I agree that DB's may not be the best choice for SystemsSoftware, but I find them great for custom applications.

Well, I guess the real point I should have made was that some people are lazy and just find it easier to "roll their own" in OO..because you already have your compiler open (or your text editor) and it is easier to just create a few objects (or recently, XML files) and integrate them into the app. If there was an easy to use EmbeddedDatabase system that people could integrate into their applications, it would make it so much easier. I'd love to see all the XML replaced with embedded databases. And large config files could also be replaced with them. Still use config files for really small things though.

These are in fact standard database operations that are never reimplemented. That point stands despite the fact that, yes, C/C++/Java/etc are Turing Complete and can be used to implement these and much more. I think the original phrasing "..are terms for typical database operations..." was completely fair. Possibly TopMind doesn't understand non-DB programming, but also possibly his detractors aren't steeped in DB paradigms. -- DougMerritt

I don't know if I'm completely steeped in DB paradigms, but I've been soaking in them long enough to get wrinkled fingers. The problem is that every time someone uses one of these verbs in OO code, Top sees that as evidence that an RDBMS should be used. Although these verbs are used for typical database operations, use of these verbs doesn't demand the use of a database. These verbs are used for typical set and file operations. Database operations are one instance of those, but not the only instance.

Is it the topic name that bothers you, or the implication that seem to come with the topic name? Lets consider some alternative names, how about. -- top

It is the way you use the topic name. These are mostly set verbs. Databases manipulate sets, but they aren't the only tools that do so.

Ok, fair enough. Still, don't overreact. RDBMS is a definite paradigm, and for certain things, a handy one. It is a mistake to insist on using a relational database for every kind of programming, but it is also a mistake to go to the other extreme and, for instance, re-invent databases piecemeal and badly without making full ACID guarantees -- and this has in fact happened quite often. -- AnonymousDonor (not-top)

It is actually impossible to use a relational database as the baseis for many kinds of interesting and useful programming; creating devices that are aware of and responsive to their environment without recording and manipulating complicated state history data come immediately to mind.

Skipping the ACID part and looking just at one of the operations that is a key part of the paradigm, filtering, it certainly isn't necessary to always use an RDBMS for filtering. One of the really handy things about the Unix shell is that it supports ad hoc searching and filtering of text files and streams, for instance. So filtering is part of the Unix shell programming paradigm, too.

On the other hand, while filtering can be implemented in any programming language, it isn't part of the paradigm for most languages, and this makes a difference. When I create a new collection class in C++ or Java, I need to be on the ball and reimplement filtering on that class, too, or else I lose the power of the filtering paradigm. It is not pervasively available as it is in the shell.

Is that an argument for always using an RDBMS? Heck no. It's an argument for doing all programming in the shell. Just kidding! :-) -- dm

All these things are pervasively available in Smalltalk, Ruby, Python and Lisp, among others. -- RobertChurch

This issue taken up in DedicatedStructuresVersusRdbms.

EditHint: I am half-planning on renaming this topic to CollectionOrientedVerbs. Any objections? --top

See also: InterfaceFactoring, WhenAreStandardsRestrictive, ModularProgramming

EditText of this page (last edited November 26, 2012) or FindPage with title or text search