Re: Application logic and Business logic

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 03/07/05 

Date: Mon, 7 Mar 2005 17:26:42 +0100

On Mon, 07 Mar 2005 07:19:26 -0500, Thomas Gagne wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 05 Mar 2005 14:31:12 +0100, Alfredo Novoa wrote:
>>
>>>On Sat, 5 Mar 2005 10:14:24 +0100, "Dmitry A. Kazakov"
>>><mailbox@dmitry-kazakov.de> wrote:
>>>
>>>>The very idea of DB is archaic.
>>>
>>>What a nonsense!
>>
>> Yes I meant exactly that. The idea of physical separation data from
>> application is archaic. Data without application is memory.
>
> But memory without structure is gibberish, and gibberish can't be shared
> between applications.

Right. More to the point, the idea of sharing data between applications is
also archaic and dangerous. What could be shared data *in* an application?
Right, they are volatile global variables! Would somebody here argue for
global variables? For ones as a synchronization mechanism? It was obsolete
already in 70s, its was always obsolete.

Further, the applications "sharing" data just comprise another larger
application in which data exist as, right, global variables. It is a very
old, archaic, fragile, error prone architecture. First there must be
objects of types, not just data. Second the scopes where object exist
should be chosen according to the application logic and not implementation
logic.

> I have little idea how your brain stores information but it works well
> for running dmitry.exe. I've little clue how tom.exe organizes my
> brain. My guess is tom.exe and dmitry.exe wouldn't run well if we
> swapped brains, neither could both applications run on the same brain.

Any comparisons to brain are of course inherently flawed. Just because not
everybody accepts that what X.exe does is computable. I don't take it for
granted. But even so, where you see DB in your brain? Do you feel making
"select *" when you think about something? (:-))

> Believing DBMS are archaic compared to unlimited memory is romantic and
> I believe a POV shared by Martin Fowler (which may give it weight), but
> it doesn't really work. The point of saving data to a DBMS is not only
> to give it persistence, but to (more importantly) share it with other
> applications. To share the data all the applications need to know where
> it is, how to access it, how it's organized, and what is inside it. The
> data created by any single application is used at least four times more
> often by other applications.

I think I have answered that above. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Relevant Pages

  • Re: Application logic and Business logic
    ... Data without application is memory. ... I have little idea how your brain stores information but it works well ... neither could both applications run on the same brain. ... Believing DBMS are archaic compared to unlimited memory is romantic and ...
    (comp.object)
  • Grey stuff: haw far neuroscience has got
    ... "This first report from the Brain Waves project is a series of essays ... neuroscience and neurotechnology and discuss the translation of this ... knowledge into useful applications. ... Neural interfaces and brain interference - Professor Irene Tracey, ...
    (uk.politics.misc)
  • Re: OT: eMotiv Launches Brain API for Developers of EPOC Neuro-Headset
    ... brain signals are immediately picked up by the machine. ... applications to remotely control computer, tv, lights, phone, radio, ... The applications developer is able to utilize the Brain API which ... "packages" or suites: ...
    (comp.lang.java.programmer)
  • Re: Chinese knife
    ... exercising your brain. ... stainless steel. ... Some applications require harder than SS can deliver. ...
    (rec.food.cooking)
  • Re: xmalloc string functions
    ... require memory allocations depending on the way the system works. ... If the toolkit being used is not one of those, then it is irrelevant that some provide a means to do so, particularly if the "some" are not available for the platform being targeted. ... Not enough context for most real-world applications to recover at this point. ... At this point g_malloccalling abortbecomes a moot point, particularly if your auto-save code is robust against memory allocation errors. ...
    (comp.lang.c)