|
|
Re: Hiring the Rowing-Forward 30%
|
Posted: Apr 21, 2008 3:30 AM
|
|
> The relational model is not about tables, that's just an
> artifact of SQL implementation, currently. There are, as
> yet niche, RM databases which are column stores. Whatever
> can be specified in hierarchical/network terms can be
> built better (more compactly and efficiently) in a
> relational database. One does need some training to know
> that.
>
> Dr. Codd proved, since he was out to skewer IMS (aka, xml
> in today's jargon), that the relational model of data was
> not only the best, but first, model of data. The
> hierarchical (xml) and network (sorta kinda, object)
> databases of the time were passive stores for the code,
> generally COBOL, with a bit of PL/1 to the side. It's the
> ignorant younguns who, not having done or studied
> databases, think that xml (the usual suspect, but OODBMS
> too) is some brand new magic bullet. It is not. It is a
> proven dead end.
Ugh! Extremism! IMO, stating that OODBMSs are a dead end is plainly wrong. It all depends on what you are using it for. I have a hard time believing that the native, hierarchical database traditionally used for directories is a worse solution than a relational one. I'm sure there are other examples too.
You probably wanted to say that relational databases have a far wider domain of applicability. This I can agree to.
> Those who ignore the past are doomed to repeat it. And so
> it is in IT; perhaps more than most other "professions".
> I mean, would any civil engineer now build a bridge in
> the manner of the Brooklyn one? That way was abandoned,
> for good reason. But IT folk will hype old wine in new
> bottles, if they see a way to make a buck; or lack the
> smarts to understand the math.
:-) This, IMO, has something to do with IT being comparatively a pretty young field, on one hand, and on the other hand being significantly different than other, more established, engineering domains. Not (only) with the vast majority of programmers being not quite as good as they should be.
> The notion that xml is a data model is false. But one
> needs to have read the history of data and data models (as
> distinct from specifications). xml is a specification.
> It has no algebra.
>
> The point of my comment, in context of the OP, is that by
> returning to the thrilling days of yesteryear where data
> is subsumed to (by definition) client code, we return to
> the bad old days of fragile data. Worrying about *coders*
> is the problem. Coders view data as mud, to be shaped as
> they see fit. For some kinds of systems (games, for
> example) this is fine. For multi-user, transaction driven
> systems, this is the wrong question. For such systems to
> be robust, the data must have precedence. Clients only
> draw pictures of the data.
You say it yourself! It all depends for what you do the app.
Could it be that you you mean only a subset of all enterprise-level apps being developed/used nowadays?
The apps we usually do are ones with highly dynamic data models, with ever changing requirements, and I can tell you for sure that relational databases simply get in the way. Unfortunately, there's no real alternative (OODBMSs are way to weak, in what functionality we could use) to RDBMSs, so we have to use ORM tools/frameworks/toolkits/libraries.
However, there are also occasional projects where we know that the amount of data will be small, the user will typically be working with maybe a few dozen objects at a time, not more, and most of the work will be done offline - the highly dynamic evolution of the data model staying just the same. Now what use would be a relational database be in such an app?
> The cure is to seek and employ smart data folk, whenever
> the system is multi-user, transactional, and has a need
> for "data persistence". That's not all systems, just the
> ones that matter.
I think this is way overstated. Why would anybody pay for systems that don't matter?
> To the extent that au courant buzzwords like SOA and RIA
> get managers and the like thinking that they can ignore
> the database's natural control of the data, and have
> "intelligent clients" reading and writing where they will
> when they will; there lies the path of perdition.
I guess you are a bit behind some issues in the industry - the business issues. I'd really love to see you develop an app integrating about a dozen data sources, each with its own access technology, then maintain the app with minimal effort while the data sources keep changing technology and structure. And do this without some decoupling layers (let's call them services) in betwen.
Just an example: my company buys us lunch every day. Our caterer publishes the weekly menu on the web. We need to do weekly orders, but there's no such facility provided by the caterer. Even if it was, the caterer would probably be unwilling to manage company and employee accounts for each of his customers. You can be darn sure the caterer needs a proper database containing all orders for one week ahead. Nevertheless, what's the use of this database to us? Do you think we will ever get access to it, in order to develop an app siting atop of it, so we can order online? That's where web services have their place, and where nothing else (IMO) can do a better job. We did an app which reads the weekly menu from the web, publishes it internally, lets all employees place the orders, then, only when time is due, places the order for next week.
Could you call this app critical? I guess not - we could surely do the ordering by mail, if there was no other way. But doing it this way saves time, both for the caterer and for us. And you know, time is money.
|
|
Previous Topic
