|
|
Re: DB-or-bust
|
Posted: Sep 24, 2005 1:41 PM
|
|
> i vote for putting the code not in the application(s), if
> only to avoid the duplication (and lack of accurate
> duplication, of course). DRY is au courant, but coders
> rarely see that the database is the best place (barring
> clear evidence to the contrary) to make this happen. the
> individual coder seeks to not repeat s/heself. blissfully
> ignoring all those other folks who end up repeating the
> same code and/or data (with egocentric variations, of
> course). this is progress?
So, what you're wanting to do is make the whole universe fit in the database. The only way that can possibly work is to add all sorts of dirty stuff that code is currently used for. And so how would that be progress? Back to monolithic jumbles?
> > Seriously? Ouch. For the current crack, check out the
> > Model-Driven Architecture hype and reality -- CASE
> lives.
>
> MDA is not database driven. i just googled the OMG-MDA
> FAQ. database is not used even once. such was my
> recollection.
As sorry for the too-abrupt segue. MDA suffers from the same basic delusion -- that one thing can be everything for everybody.
> > Also, have you looked at all of the abject failures in
> > the DB-is-everything approaches to building web sites?
>
> cite a couple of examples, and i'll go look at the
> craters.
There everywhere. Do some searching. If you can't find them, look at it from the other direction: Where are all of the purely database driven solutions (and, if they are so much better, why haven't they wiped the floor with all of the other crappy solutions :-).
> > Ando those are relatively simple.
> >
> > No, that's exactly the point. SQL can't get the job
> done
> > by itself. It's fundamentally incomplete and broken.
> > Seriously, Date's book that I mentioned makes very
> clear
> > r arguments of this.
>
> but Date *doesn't* argue that data control, a posteriori,
> should be in countless application codebases. he, and
> Pascal, argue for strengthening the database, not
> abandoning it. read them on OO and XML; bring your
> asbestos undies. you won't find any support from them.
Sigh. This DB vs. the rest of the world chip on the shoulder is really boring.
Date is talking about the Relational Model. That's a very different thing from SQL databases. Yes, maybe someday an actual database system will be built that is precisely the relational model. That's completely irrelevant to this discussion (AFAICS) because Date recognizes that the relational model isn't, by itself, sufficient to cover all of the capabilities of a complete software system (it's "merely" a necessary component). I.e., as I've said, the database-is-everything approach is just as broken as any other such simplistic notion.
> > (A) My question was about whether the popularity of e.g.,
> > unit testing has had any beneficial effect on programmer
> > mentality w.r.t. quality. Yes, of course other approaches
> > such as DbC have a lot of overlap therewith but they
> > haven't ever caught on like the JUnit-instigated unit
> > testing "fad".
>
> it encourages coders (used globally) to not put much
> thought into what they're doing. the tester will find all
> the bugs, so, What, Me Worry??.
I think you're confused about what "unit testing" means. (A) "unit tests" are created by the developers. (B) Ala TDD, the tests are typically written before the code and so, by definition, the developers are having to think about what is being created.
> "fad" is a synonym for
> "herd". we've seen where that has brought the world
> lately, now haven't we? fact is, there are few high-order
> thinkers in this world. generally, where the "herd" goes
> is where i try to avoid. herds don't have high-order
> thinkers.
So the fact that herd is making progress is irrelevant to you?
> > (B) What does the question about e.g., unit testing
> > mindset have to do with the question of perfection? Is
> > anything in this thread about perfection? Aren't we
> > talking about how to reduce suckage (and increase
> > goodness)?
>
> see above. but, again. when talking about the
> applications that most people deal with in a working
> environment, we're dealing with data based (DB or files or
> whatever) programs with a UI. suckage in this milieu
> comes down to one of two things: the app is harder to use
> than the one i had before; the app screwed up the data
> that i gave it. for this arena, where some of the
> programming world is going, back to language/data, is
> retrograde. and the source of the suckage.
IME, a very big chunk of the anti-DB-centric movement is actually a reaction to the suckage of the DB-centric worldview. The complexity of the unified, centralized DB has shown to be very costly and very brittle. I do like the Agile Database movement as it's helping to break down the brittleness issue into something more manageable.
> if someone posited that the COBOL/VSAM paradigm was the
> apotheosis of programming in 2005, wellllllllll. but,
> structurally, java/object, is really no different. both
> assert that the data belongs to one set of code, written
> in one language, and that access to the data *must* (even
> read) go through that code. code independent access to
> data, read or write, is forbidden. i object to that. and
> it makes for suckage for this class of users. business
> data is being tied up in java just as tightly as it was
> tied up in COBOL in the 1970s. this is progress?
As I've said repeatedly, the code-is-everything approach is just as broken as the DB-is-everything approach. They are merely two ends of the same paradox. I'd like to get to the question of what's the unification/transcendence of that paradox because I think that's the only way out of this "religious" war.
> and don't start with the "XML is a great database" stuff.
> please. the idea is not the progeny of high-order
> thinking.
I totally concur.
> > (C) The unit testing fad is part of the TDD movement.
> > I.e., the incremental, write-test-first worldview rather
> > than the reactive, post-code testing approach.
>
> well, there is the think-about-it-and-design-it-right way
> too. the TDD cult assert that this is not possible, so
> why try?
I totally agree that the extreministas all-too-often hamper the reasonable and rational discussion of adaptive, feedback driven design. That incalcitrance aside, there's no fundamental conflict between good thinking and adaptive, incremental, and feedback driven development. It's just another spectrum -- no single point on the spectrum is magically the best spot above all others for all contexts. IMHO, the point to focus on is the adaptivity to use what works well in the context.
|
|
Previous Topic
