Re: too much OOP ?
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Fri, 4 Jan 2008 10:27:40 +0100
On Thu, 3 Jan 2008 21:17:54 -0800 (PST), frebe wrote:
Who's mindset are you talking about, mine? Regardless the mindset, do
you think it is a mistake to use SQL databases in applications for
accounting, invoicing, inventory management, etc?
That depends on the functional and non-functional requirements of each
concrete system. The two basic ideas - of separation of data from semantics
(meaning) and of client-server architecture are ugly remnants of deep past.
So building an application for inventory management without an
relational database is actually an option for you?
I must see the requirements first. If they do not contain "shall use MS
Access," then I would certainly consider this option.
Would it be better
to use some other kind of database instead or implement the data
management logic in the application instead?
If you can factor out these accounting etc as an abstraction, then do it. I
just don't see why it should be "database." Call it "accounting subsystem."
There is no "data management logic," there is only logic of "accounting."
This logic is implemented by the program. Who runs the program is of no
interest.
Don't you realize that by abstracting "data management" logic, one can
create components (database engines) that handles this logic in a
generic way. At least you would use some low-level data management
components like arrays and maps? Relations are a more high-level way
of doing it.
It sound like you want to write all logic from scratch? Wouldn't you
benefit from pre-made reusable components?
I am vehemently for reusing containers. I am against equating the logic of
some specialized class of containers (in this case
RA+persistence+concurrency+SQL-interface=SQL database) to the logic of an
application.
If you try to express all application logic exclusively as one of
containers, to think it as containers, then we are exactly where this
discussion started. It is low-level when it works, otherwise it doesn't...
Others
quietly create their *libraries*. They might call them "engine",
"middleware", "framework", but show nothing alike that manic disorder the
former suffer... (:-))
What libraries are you suggesting instead of a SQL database? Please
show me some example.
There exist lots of container libraries. I see no need in a special
language in order to implement RA at the library level. There might exist
issues of making the syntax sugar sweeter (for returned tuples etc). But
that is irrelevant, after all SQL is far uglier than anything the most
poorly designed library could ever present...
Now I have a question to you. Why don't you implement RA (as it has to be
in your opinion) at the library level in some decent OOPL? Make it in
several variants with concurrency and persistency support as options. I bet
OO folks will embrace it. That dead DB horse you'll sell to no one.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- References:
- Re: too much OOP ?
- From: Daniel T.
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- Prev by Date: Re: too much OOP ?
- Next by Date: Re: too much OOP ?
- Previous by thread: Re: too much OOP ?
- Next by thread: Re: too much OOP ?
- Index(es):
Relevant Pages
|