Mental State Of Missouri

I am from the mental state of Missouri.

Would that then make you a RedneckRelationalWeenie?, top?

Rednecks are people too

If you wish to convince me of something, you have to show me it working in practice. I don't want to hear vague brochure-talk or your escapades in MentalMasturbation. I want to see specific code and specificly what is better about it. If you need to apply change scenarios, that is fine as long as your scenarios and assumptions are documented.

The above, it would seem, ought to apply to TableOrientedProgramming as well as anything else. OO and other paradigms have zillions of lines of functional code. You've got...what?

I don't claim that my technology choice is objectively better, only that it is not objectively worse. The reasons for my preference may be purely a local mind-fit.

Which is find. However, you spend an inordinate amount of time trying to convince world+dog to move away from OO and towards more extensive (and pervasive) use of tables as the preferred data structure for all sorts of application programming. If your recommendation's selling point is that it's "not objectively worse", then you will have a difficult time convincing anybody of anything. "Change to this new untested paradigm, it's no worse than what you got now" is not a compelling argument. Regarding local mind-fit; that's fine. Nobody is telling you to give up relations; lots of us like the RelationalModel and find it a great solution to a wide variety of problems. But we find things like other data structure, objects, FunctionalProgramming, and numerous other tools in the GoldenToolbox? to be equally valuable. Just because you can drive nails with the back of your wrench doesn't mean you should throw away your hammer...

I can visually pick up patterns much faster in tables than as code. I don't pretend that this applies to all others (although objectively it can be a OnceAndOnlyOnce improvement because the row and column name are not repeated for each "cell", the way it is in code). I only claim that T.O.P. may have a decent WetWare niche and that OO proponents often ignore WetWare issues, and never claimed or implied TOP was objectively better, unlike the other camp.

It need not be repeated in code; don't confuse XmlDatabase stupidity (or the shortcomings of certain programming languages) with good programming technique.

It's either repeated, or misaligned. If you repeat the field names (XML-style), you have a OnceAndOnlyOnce violation. If you use positional parameters, then they don't line up well, making them hard to see as columns. If they do line up, either it's more finger busywork on part of the programmer, or your code editor is re-inventing a TableBrowser anyhow, which would prove my point. QED. -t

Most of my run in's with other WikiZens are from those who insist their pet techniques are "clearly", "objectly", and/or "vastly" superior. I will hold them to such claims until they either prove it or withdrawl the claims. I am a kind of Science Cop, if you will. -- top

Many of the pet techniques advanced here do have significant research and practical use behind them.

Nope. Comparative benefit research in IT is still in the dark ages. See DisciplineEnvy. As far as, "many use it and it works", well, so does Cobol and assembler.

And again, I don't see too many people calling for getting rid of databases. Maybe the OrthogonalPersistence folks think they'll one day obsolete explicit persistent stores (including databases, filesystems, etc.) but that strikes me as SyntacticTupeloHoney.

Again, DatabasesAreMoreThanJustStorage. If you see them as ONLY storage, you are missing their point.

I certainly don't see databases as only storage; if all I need is just "storage" I probably don't need a database. Databases are important for transaction semantics, data integrity constraints, shared access from many users and applications, durable storage, etc... you know that and I know that. OTOH, I don't see databases venturing too effectively into the realm of replacing transient data structures--that strikes me as both an AbtractionInversion? and an AntiPattern.

I have used things approaching MinimalTables successfuly for "transient data structures". And, MinimalTables can scale (code-wise) into full RDMBS with far more ease than OO equivalents.

The case for RelationalDatabases in enterprise application software has been convincingly made; I do not dispute it one iota. The case for TableOrientedProgramming--the use of relational databases as the primary means of structuring programs, has yet to be made. OOP, on the other hand, has been demonstrated an effective manner of structuring programs. Perfect? Certainly not. But for TOP to replace OOP, it needs to be shown to be better. You haven't done that. Claiming that TablesAndObjectsAreTooDifferent--and that therefore we should abandon objects--is an insufficient argument.

Task-based code grouping (common in DB-centric shops) is probably still more common than OOP, with its noun-based or mixed grouping tendancies. (Think of all that Cobol code still out there.) Thus, why is the burden on task-based instead of the other way around? -- top

(AmericanCulturalAssumption: The state of Missouri is known as the "show me" state, known to be skeptical and distrustful of "sales talk". It's also the home state of one JohnAshcroft, though the good folks of Missery :) had the keen sense to boot him out of the Senate, electing a cadaver instead. 'Course, that made him unemployed and thus a prime candidate for the Attorney General's office...)

Perhaps this can be merged with RaceTheDamnedCar.