About Entity-Relationship Diagram in BDS 2007
Bear
Since ECO has the powerful support for UML design,
do you think it is a good idea that ECO supports Entity-Relationship Diagram
in BDS 2007?
So the BDS developer can draw E-R diagram and generate SQL script to create
the database for MS SQL, MYSQL, DB2. ....
It will save us a lot of time. And it will save the money to buy something
like PowerDesigner.
It will make BDS much more valuable.
P.S. Do you need design Entity-Relationship Diagram in your database
project?
Thanks
Bear
mramirez
>Entity-Relationship Diagram
>in BDS 2007?
YES.
>P.S. Do you need design Entity-Relationship Diagram in your >database project?
Yes, I do. And I don't use ECO, yet. Delphi, yes.
Many of us can't change to 2007, right now.
Another reason is that UML is powerful, but sometimes complicated. Some third-party programs provide a "UML lite" or "UML like" E-R diagrams, such as:
-Case Studo
http://www.casestudio.com/enu/default.aspx
-Context Database Designer
I don't work for those companies, Im just mention them.
Add the one you like.
Many of my programming students or coworkers use E-R
instead or UML.
I find better, to usually explain to them,
E-R combinated with Yourdon "bubbles" method,
AND LATER, MOVE TO UML.
Just my 2 cents.
Joanna Carter [TeamB]
4469...@newsgroups.borland.com...
| Since ECO has the powerful support for UML design,
| do you think it is a good idea that ECO supports Entity-Relationship
Diagram
| in BDS 2007?
|
| So the BDS developer can draw E-R diagram and generate SQL script to
create
| the database for MS SQL, MYSQL, DB2. ....
| It will save us a lot of time. And it will save the money to buy something
| like PowerDesigner.
| It will make BDS much more valuable.
IMO, the move nowadays is to design OO systems and mediate between that and
a database, rather than starting with the database design and then connect
data-aware controls directly to tables.
Many people now use an object modelling tool like ECO or other OPF to
generate a database to support an object model; there really is no need for
an E-R tool as the entities and relationships are described in classes and
interfaces; the database becomes a dumb datastore that holds simple tables,
one per persistable class.
Delphi is so much more than just a database development tool; good program
design starts with the object model and then either maps to a legacy
database or uses an OPF to create its own automatically from the object
model.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
TObject
"Bear" <Be...@nobody.com> wrote in message news:4469...@newsgroups.borland.com...
> P.S. Do you need design Entity-Relationship Diagram in your database
> project?
Yes, I use PowerDesigner.
Unfortunately, I don't think Borland has resources or expertise to build
something like that. It would be another new thing for them, and constitute
spreading even thinner than they already have.
Bear
Did you try PowerDesigner? The free trial is available:
http://www.sybase.com/products/developmentintegration/powerdesigner
Images:
http://images.google.com/images?q=powerdesigner%20&btnG=%E6%90%9C%E7%B4%A2&hl=zh-CN&newwindow=1&sa=N&tab=wi
I think it is the best database modeling software. (I also used CaseStudio
etc)
It can also a UML modeling tool.
I used it to design database in each project when I was in a bank.
It is as expensive as Delphi.
The most useful thing is that it can generate database script from my E-R
diagram.
>>UML is powerful, but sometimes complicated.
Yes
For small projects or normal database projects, I think E-R digram is more
important than URL.
In many cases UML is just a documenting tool or thinking tool, we can do
that by Word or Visio.
But for complicated project or big team, UML is very useful to communicate.
I think adding a E-R diagram based on UML function in BDS is easy.
If the diagram has Entity and Relationship information, it can generate
database script via Templates for different database.
Bear
"mramirez" <mram...@nospam.org> 写入消息新闻:4469...@newsgroups.borland.com...
Bear
> IMO, the move nowadays is to design OO systems and mediate between that
> and
> a database, rather than starting with the database design and then connect
> data-aware controls directly to tables.
1. I think OO is just a tool, we should use it only when we can benefit from
it.
2. There are still a lot of people "starting with the database design and
then connect
data-aware controls directly to tables".
If it can finish the project quickly it is correct.
> there really is no need for
> an E-R tool as the entities and relationships are described in classes and
> interfaces; the database becomes a dumb datastore that holds simple
> tables,
> one per persistable class.
3. if the database becomes a dumb datastore that holds simple tables, I
think it is only for small projects or simple database.
in big database(e.g. the databases in a bank), the E-R diagram is very
important,
and many critical business logic are implemented in database level not
Application Server level.
Now Database is powerful(PK,FK,index,default value, stored
procedure,...).
>
> Delphi is so much more than just a database development tool; good program
> design starts with the object model and then either maps to a legacy
> database or uses an OPF to create its own automatically from the object
> model.
4. I am new with ECO and O/R mapping.
The core of database application is business logic.
if i want to develop a 2-tier or n-tier application, it seems that ECO or
O/R mapping make it complicated.
In a demo, a little girl used ECO generate a simple database program.
In fact, if the program know the E-R diagram, it only need one click to
generate the whole project source code with database module, forms,
navigation functions, and well named components.
I have a small program to do the this for any database. Then I copy the
components I need from it to my real project.
And ECO need .NET.
So I would happy if Delphi can
1. Let us design E-R diagram
2. Generate database schema script for MS SQL, Access, MYSQL,
Interbase, Oracle,....
3. Generate prototype application -- a whole project source code to
maintain the database (add, edit, delete,save) with well named components.
It is a sales point too. :)
Bear
"Joanna Carter [TeamB]" <joa...@not.for.spam> 写入消息新闻:446a0666$1...@newsgroups.borland.com...
> "Bear" <Be...@nobody.com> a 閏rit dans le message de news:
Abdullah Kauchali
"Joanna Carter [TeamB]" wrote in message:
>; there really is no need for
> an E-R tool as the entities and relationships are described in classes and
> interfaces; the database becomes a dumb datastore that holds simple
> tables,
> one per persistable class.
OMG!
Joanna Carter [TeamB]
446a...@newsgroups.borland.com...
| OMG!
That's right. The Object Management Group is responsible for standards in
OO, UML, etc.
;~}
Eric Grange
> a database, rather than starting with the database design
Personnally, I've yet to see a single system designed that way that was able to
scale and evolve properly, maybe all those I saw were unlucky attempts, but they
all collapsed when attempting to grow beyond a handful of users, or when data
size grew beyond a few dozen MB of "live" data.
> good program design starts with the object model and then either maps
> to a legacy database or uses an OPF to create its own automatically
> from the object model.
The problem IME with designing the DB from the OO, is that the OO layer is both
more than "just data" and less than "DB aware" (f.i. transaction concepts are
typically not expressed, nor are relations in the relational DB meaning).
DB structures are best left mapping to the data, and only the data as it *is*,
rather than how you think you want it manipulated/accessed.
A relational DB can be so much more than an object model in many ways, and
assimilating a DB table to being merely being a form of indexed list container
for object storage kinda misses the point: it's a case of a blacksmith seeing
every tool as a hammer.
The same DB scheme can support being manipulated by multiples families of
objects, that will all provide a different view angle on the same data, *if* the
DB was designed independently from the objects.
If not, whenever some late requirement or evolution request gets in that puts
part of the initial OO perspective on the wrong foot, you risk facing impedance
match issues that will result in patching up, tears and frustration.
Eric
Joanna Carter [TeamB]
446ab54b$1...@newsgroups.borland.com...
| The problem IME with designing the DB from the OO, is that the OO layer is
both
| more than "just data" and less than "DB aware" (f.i. transaction concepts
are
| typically not expressed, nor are relations in the relational DB meaning).
| DB structures are best left mapping to the data, and only the data as it
*is*,
| rather than how you think you want it manipulated/accessed.
Certainly the OO layer is *much* more than "just data" and it certainly
should not be "DB aware".
However, this does not preclude the concept of transactions or relations.
Transactions are implemented at an object level within the design of a good
OPF (like mine ;~}).
My understanding of "relation" in RDBMS terms is that it is most commonly
called a table but is, in fact, any predefined column/row format. This
concept is catered for in OO terms as a list of objects, although it can
also be realised as a "data packet" like serialisation, XML, etc.
Objects are usually a mixture of both data and code, although there are
occasions where you find classes that are totally data with no code or
totally code with no data.
My frameworks use the concept of a data packet inside any persistable class;
this packet is what gets passed to or returned from the persistence
mechanism.
| A relational DB can be so much more than an object model in many ways, and
| assimilating a DB table to being merely being a form of indexed list
container
| for object storage kinda misses the point: it's a case of a blacksmith
seeing
| every tool as a hammer.
If a RDB is more than just an idexed list container, then that assumes that
some of the business logic is also placed in the the DB. This then takes us
back to the bad old days where we have data in one place and functionality
in another. Admittedly the data and code are both held in the same database,
but that is like saying global variables and code are held in the same
program in a procedural application. What is more, most DB led applications
have *some* of the business logic in the database and the rest in th UI
layer.
Good, well designed OO applications separate out *all* business logic into
the business layer in such a way that it is possible to test the integrity
of the business logic without ever touching a database or visual control.
Many Delphi develpoers who eschew OO design complain that using objects
stops you using data-aware controls and therefore limits/retards application
development by not making use of RAD facilities. In .NET, we have the
concept of data-aware controls that can be linked to properties of objects,
or list of objects, instead of just fields in tables.
So now we have a mechanism that allows us to use RAD to design
visualisations of objects and their properties without any reference to a
database, all that is left for the avid RDB enthusiast is the requirement to
persist objects between sessions. Microsoft are already previewing LinQ; a
language/framework extension that allows the querying of list/graphs of
objects in native C# code, rather than having to maintain a separate SQL
codebase in the database. Th eidea is that the same query syntax maps, not
only to lists of objects, but also to tables in databases.
| The same DB scheme can support being manipulated by multiples families of
| objects, that will all provide a different view angle on the same data,
*if* the
| DB was designed independently from the objects.
This is where a good OPF or ORM comes into its own; allowing a programmer to
specify mappings, either to legacy databases or simple "indexed list"
databases, thus allowing use of the same data by applications that are not
object-based or by object frameworks that translate the objects to/from
tables or stored procs.
Good OO design does not preclude the use of a relational database, well
designed or not, it simply provides adapters that allow the object world to
function in blissful ignorance of how instances of classes get persisted.
| If not, whenever some late requirement or evolution request gets in that
puts
| part of the initial OO perspective on the wrong foot, you risk facing
impedance
| match issues that will result in patching up, tears and frustration.
Once again, the key to good OO design is to work with a good OPF that is
designed to be as flexible as any RDBMS; something that I have achieved with
my frameworks.
There is no reason why OO applications cannot scale to any size, in fact
there are systems out there that are in everday use that support multiple
thousands of users over multiple continents; you just haven't come across
them yet :-)
K. Sallee
> there really is no need for an E-R tool as the entitiesand relationships
> interfaces
For an OODBMS I agree, but with a RDBMS I disagree. ER Tools are quite
useful to understand table relations in a RDBMS.
Kevin
K. Sallee
>> the database becomes a dumb datastore that holds simpletables,
I think Joanna's choice of words were unfortunate because it can cause
this response, but you have to consider that with a true OORDBS this is
probably pretty accurate. Not everyone today needs an OORDBS of course,
since OORDBS and RDBMS still serve different markets, while others are
just in situ and unlikely to change soon.
Kevin
K. Sallee
> database script from my E-R diagram.
Then you should look at :
http://www.azzurri.jp/en/software/clay/index.jsp
"Clay can also create a database model by reverse engineering an existing
database. Furthermore, Clay generates the SQL (DDL) code appropriate for
your database."
Kevin
K. Sallee
> OORDBS
Well now... that was a persistent typo. rather: ODBMS
Kevin
Bear
Thank you for your link very much!
It is free too.
http://www.azzurri.jp/en/software/clay/images/clay_eclipse_1.png --> It like
PDM(Physic Data Module) in PowerDesigner.
As a free software, that is enough. If it can provide CDM (Concept Data
Module) function that will be wonerful.
Bear
"K. Sallee" <nono...@nonono.net>
??????:ops9oy8o...@ecologsoft.ecologicalsoftwaresolutions.office...
Hrvoje Brozovic
> IMO, the move nowadays is to design OO systems and mediate between that and
> a database, rather than starting with the database design and then connect
> data-aware controls directly to tables.
>
> Many people now use an object modelling tool like ECO or other OPF to
> generate a database to support an object model; there really is no need for
> an E-R tool as the entities and relationships are described in classes and
> interfaces; the database becomes a dumb datastore that holds simple tables,
> one per persistable class.
>
> Delphi is so much more than just a database development tool; good program
> design starts with the object model and then either maps to a legacy
> database or uses an OPF to create its own automatically from the object
> model.
>
I tend to beleive that your databases may be dump,
but mine are not. Why on Earth will I throw away
all functionality build in expensive DB systems,
just to try to reinvent it poorely with my OO code?
But, anyhow, you often don't have any control over
database, it is already given and attacked by many
other applications. Idea that you can create fresh
database for fresh project is naive, from my perspective.
Eric Grange
> should not be "DB aware".
"DB aware" can take many meanings, that of "DB aware components" isn't
the one I meant - last time I used DB aware components was likely more
than a decade ago ;)
However a proper OO layers certainly *has* to be aware that it is
manipulating data in an asynchronous, potentially distributed fashion,
and not just structures in memory with some magically guaranteed integrity.
As long as the db hasn't returned from a 'commit' f.i., there are things
the OO layer can't assume without taking the risk of compromising data
integrity (which can be the worst kind of bug that could ever happen).
> However, this does not preclude the concept of transactions or relations.
> Transactions are implemented at an object level within the design of a good
> OPF (like mine ;~}).
Alas, this makes it one of the exceptions IME... Most of the models I've
ever seen were working in some kind of "ether" (for lack of a better
term), when they didn't potentially have to be fully loaded in memory
for some operations, and then fully written.
Of course the first power or hardware failure meant you had to revert to
the last backup, if you were lucky enough to find it still functionning,
and it also meant that to backup, you had to stop the whole thing.
> If a RDB is more than just an idexed list container, then that assumes that
> some of the business logic is also placed in the the DB.
Not really, business logic and data structure are different notion.
Business logic, you'll find it in triggers or stored procedures, rather
than in relations.
For instance, if I have items, orders and customers, the links between
the three do not depend on how customers, orders or items are
manipulated, they are data. You can define DB structures that will suit
all possible business logics that manipulate items, orders and
customers. And you can even define data structures that will provide
adequate querying performance without even knowing how or what you'll be
querying.
> This then takes us back to the bad old days where we have data
> in one place and functionality in another.
Well, IMO this is exactly what happens when the DB structure is derived
from the object model, as the object model implicitly merges business
logic and data ('data' as in fields, members, structures rather than
'persistence'), if you derive the DB from it, then you derive this
implicit merge as well.
To keep on the items/orders/customers example, one case recently
encountered was one where instead of designing the structures out of the
blue, they had designed them from an OO perspective to fulfill their needs.
So initially, they had made a list of customers (there weren't many),
that had orders attached to them (they had lots of orders), that had
items attached to them (they had "zillions" of these).
Since they had "zillions" of items, instead of having a distinct 'items'
entity, they had made the 'items' into mere items of an order, and order
ending up as a sort of spiced up array of items.
This all worked out well enough until they realized they didn't have
that many zillions of items, wanted to have standard items and wanted to
search to which customers some particular items had been sent to...
Had they designed the DB structure from the data they had to manipulate,
before even considering how they would manipulate it, they wouldn't have
been faced with the inextricable hard-to-index monster of duplicates and
near-duplicates their expanded items "table" had grown into.
> Many Delphi develpoers who eschew OO design complain that using objects
> stops you using data-aware controls and therefore limits/retards application
> development by not making use of RAD facilities. In .NET, we have the
> concept of data-aware controls that can be linked to properties of objects,
> or list of objects, instead of just fields in tables.
I'm not fond at all of DB-aware components, but I'm not too fond of
objects that abstractly edit other objects (ala property inspector, or
ala editor linked to another object), IMO it's a bit too much like
DB-aware, just at the object level.
Even for setting up components and controls in design mode, ie. while
they're not truly active, there are already versionning and behavioural
issues with both the Delphi and .Net property editors.
You also end up having code in the objects that is only there to shore
up issues with what is fundamentally UI stuff (like the change
notification chains).
> This is where a good OPF or ORM comes into its own; allowing a programmer to
> specify mappings, either to legacy databases or simple "indexed list"
> databases, thus allowing use of the same data by applications that are not
> object-based or by object frameworks that translate the objects to/from
> tables or stored procs.
Yep, OPF to access an existing DB is good, but basing the design on the
OPF, with OPFs that are so often, so implicitly focused on business
logic is just forcing business logic decision and choices all the way
down to the data... it's just asking for big bad ugly trouble unless the
object model was designed to "perfection".
> Good OO design does not preclude the use of a relational database, well
> designed or not, it simply provides adapters that allow the object world to
> function in blissful ignorance of how instances of classes get persisted.
Alas, blissful ignorance of how instances of classes get persisted has
always led to data corruption or data loss IME...
And don't get me started on the typical unability to export/import data
without significant software (code) investment.
Having a clean, data-in-the-db-first approach guarantees that the data
can survive the application. Yes, this can be seen as a commercial
weakness as you reduce vendor lock-in, but there are many cases where
data is more valuable than the application, and for which not being
locked-in is a desirable feature: RDMS and SQL weren't just introduced
to provide some indexing or querying features, but also to provide
standard means of extracting and importing data.
OO has XML and other 'modern' streams, but having seen XML dumps from
rather large, intricate OMs that had to live and evolve for years, were
maintained by different peoples with different ways of doing things...
it can truly be an inextricable jungle in there, and there are very
little tools available to help in the hunt for data.
If full import/export capability was built right from the start (and
maintained/tested throughout the application's life), then I guess it's
okay, but I can only guess as I have never encountered such a beast face
to face ;)
All I ever saw were rather raw dumps, in which to get a piece of data
you had to check in a variety of places depending on a variety of
conditions, and then you had to interpret that piece of data... Most of
the dumps were also slow to retrieve, forbidding their use for any
on-the-fly lookups.
> There is no reason why OO applications cannot scale to any size [...]
Indeed, but the success of a few is no proof that the "masses" can
succeed. OO can be very powerful, but it's also easy to get it wrong.
And when you're stuck with an OPF gone wrong, not only is your code
stuck, but your data is stuck too...
Eric
Wayne Niddery [TeamB]
>
> To keep on the items/orders/customers example, one case recently
> encountered was one where instead of designing the structures out of
> the blue, they had designed them from an OO perspective to fulfill
> their needs. So initially, they had made a list of customers (there
> weren't many), that had orders attached to them (they had lots of orders),
> that had
> items attached to them (they had "zillions" of these).
> Since they had "zillions" of items, instead of having a distinct
> 'items' entity, they had made the 'items' into mere items of an
> order, and order ending up as a sort of spiced up array of items.
This kind of mess isn't *because* things were designed from the object model
side, it is just bad design, period. In my experience of having to work on
existing databases, I've seen incredibly awful stuff - far more often than
I've seen great stuff - done by people that design the database first, and
in some cases by people that were supposedly experienced DBAs.
The *particular* kind of problems you see might be different, e.g. in the
case of bad database designers, typically the first thing you see is a
terrible lack of normalization.
That said, while I'm a very strong advocate of OO in general, and the use of
OPFs, I also have a strong database background and so agree that it is a
shame to waste many of the features built into RDMSs. I design my classes
first before (*without*) worrying about the database because I've found that
to make much more sense to me, but I don't ignore database issues either.
The separation I intially make is to distinguish between business process
rules, and data integrity rules. The latter belong in the database as FKs,
default values, constraints, triggers, etc. *Processes* though do belong
with the object model. Then, if there is some process that is proving
noticeably inefficient (because it is accessing the RDMS poorly), I will
apply whatever optimization is necessary such as doing some part of the work
in stored procedures and allowing the object model to use these.
Some don't like this (the latter part of using stored procedures) on the
premise that this is putting business logic in two places. I reject that
argument - more and more applications these days talk to other processes
whether it be via COM, CORBA, SOAP or something else, in order to do the
necessary work - IOW, it is common and very necessary for business logic to
be *distributed* already - for processes to depend on other processes that
can reside literally anywhere. Stored procs in an RDBMS are nothing more
than another object an application can communicate with in order to perform
some process. The fact that a stored proc is not technically an "object" is
completely irrelevant and a lame argument.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"A man is likely to mind his own business when it is worth minding,
when it is not, he takes his mind off his own meaningless affairs by
minding other people's business." - Eric Hoffer
vavan
<wnid...@chaffaci.on.ca> wrote:
>some process. The fact that a stored proc is not technically an "object" is
>completely irrelevant and a lame argument.
moreover in large databases it is sometimes simply unacceptable (due
to inefficiency) to divide data and logic. it is better to handle data
where it is (in dbms, there are stored procedures manipulating with
records/objects written in high-level language as oracle pl-sql)
without unnecessary overhead of passing large amounts of data there
and back between dbms and handling level
and when proper design is established client application can (and
should) use rich world of excellent data-aware components which linked
not direcly to data-access components but rather to multi-tier proxies
(such as ClientDataSet) allowing to control all data handling (via
invoking stored procedures) on appserver side
--
Vladimir Ulchenko aka vavan
Jim Cooper
> 1. I think OO is just a tool, we should use it only when we can benefit from
> it.
Which is all the time. The power of Delphi comes from OO. Doing anything in a
non-OO way is distinctly less powerful.
> 2. There are still a lot of people "starting with the database design and
> then connect data-aware controls directly to tables".
And that works because of OO.
> In fact, if the program know the E-R diagram, it only need one click to
> generate the whole project source code with database module, forms,
> navigation functions, and well named components.
But the code that is generated is not as maintainable for non-trivial projects.
The argument over whether OO is a better way to write software was decided
decades ago. Not everyone seems to realise that, of course.
Cheers,
Jim Cooper
_____________________________________________
Jim Cooper jco...@tabdee.ltd.uk
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
_____________________________________________
Jim Cooper
> A relational DB can be so much more than an object model in many ways
A relational DB is so much less than an object model in many ways.
> and assimilating a DB table to being merely being a form of indexed list
> container for object storage kinda misses the point
Actually, no it's not. The only reason we have relational databases at all is
because we have needed an efficient way to use hard disks etc as persistent
storage. If we had enough non-volatile computer memory we wouldn't use them at
all. Adding stored procs to them was just a fudge that we needed back in the day.
> it's a case of a blacksmith seeing every tool as a hammer.
I would have said something similar about people who think relational databases
are the way to drive software models.
(The common English expression is "if you only have a hammer, everything looks
like a nail". Is yours a direct translation of a French one?)
> *if* the DB was designed independently from the objects.
In practice it turns out that the DB design is very similar most of the time,
whichever way you do it. But getting business logic out of the database whenever
possible is a good thing, and designing from the problem down rather than the
database up is also a good thing.
Jim Cooper
> There is no reason why OO applications cannot scale to any size, in fact
> there are systems out there that are in everday use that support multiple
> thousands of users over multiple continents; you just haven't come across
> them yet :-)
Indeed. In the Java world, using Hibernate is almost an automatic choice (some
Java frameworks actually do use it automatically)
Eric Grange
> side, it is just bad design, period.
Personnally I'm not convinced this was fundamentally "bad design", their
object structure did fit the initial requirements, and I've seen similar
structures being used for similar looking problems in a variety of
supposedly "good design" examples.
The issue is more fundamentally that objects are neither data nor logic,
but both at the same time, and the only separation you can have is a
proactively introduced one: if you don't work for it, it won't be there.
> In my experience of having to work on existing databases,
> I've seen incredibly awful stuff
Me too, but even on the most awfully structured databases, we've always
been able to access the data, while with OPFs, we've often bumped on
unpenetrable walls... getting access to the data was only possible
through extra development from the part of the vendor with the OPF-based
application.
It typically meant that simple interconnectivity needs between
applications that could have helped the users got abandonned... there
are even situations where when the extra development was made, and when
we incorporated the data in a database on our side, we got a variety of
other services/applications knocking at the door asking to query our
database image of the data...
This resulted in a rather surprising situation where our application got
extended to present the data from the other application (data that was
useless to our application), simply because it turned out cheaper to do
it from our SQL image of their data than paying them to do the extra
screens, reports or interconnectivity interfaces on their side.
This is not a "necessary" consequence of OPFs, but in practice, this is
one we've observed. IMO it's because when you start from an OPF, getting
full import/export capability requires *extra* work that is often not
budgeted, when it's not seen as a vendor lock-in "feature".
I mean, if you have an OPF, you can make and sell a SOAP/whatever
interface yes, but the key here is "make and sell". While if you have a
DB, other applications will have ready access to your data, they may
struggle with your naming conventions or schemes, but the data is there,
and they don't *really* need you to find it.
> [...] The fact that a stored proc is not technically an "object" is
> completely irrelevant and a lame argument.
Yep. We're cross-DB though, so we avoid stored procedures to the extent
they're more likely do involve DB-specific stuff that would be hard to
replicate, but a variety a functionality is just *much* simpler and
safer to implement that way (audit change logs come to mind).
Eric
Eric Grange
> (some Java frameworks actually do use it automatically)
FWIW one of the applications that couldn't scale was precisely a Java
one using Hibernate ^_^
Eric
Jim Cooper
> As long as the db hasn't returned from a 'commit' f.i., there are things
> the OO layer can't assume without taking the risk of compromising data
> integrity (which can be the worst kind of bug that could ever happen).
This is true regardless of how you write your app, and true of more things that
database access. It's a general problem when you are dealing with any
information that resides anywhere else than the memory space of your application.
> Not really, business logic and data structure are different notion.
If by "data structure" you mean the structure in the DB, then yes absolutely,
which is why you want to put these things in different layers, where the
business logic doesn't have to deal with the DB.
I am assuming you think object orientation (putting data in a structure along
with the logic that uses it) is a good thing.
> Business logic, you'll find it in triggers or stored procedures
Which is an incredibly crappy place to have it. There are times you are forced
to do that, but it should be the exception rather than the rule.
> the object model implicitly merges business logic and data
Well, yes, since that's the very core of OO. And I would say it is explicit.
> Had they designed the DB structure from the data they had to manipulate
Or had they come up with a better OO model. I can provide examples of crappy
database design, and super crappy code that came about because someone started
with a database (even if the database design was good). We can compare crappy
designs all day and come to no useful conclusions (except maybe who not to let
design anything)
Eric Grange
> all is because we have needed an efficient way to use hard disks etc as
> persistent storage.
Blacksmith seeing every tool as a hammer.
> If we had enough non-volatile computer memory we wouldn't use them at
all.
RDBMS deal with more than just safe storage, they deal with concurrency
and transaction safety, which both require more than just lots of
non-volatile memory.
They also deal with standardized data access and presentation, and the
ability to efficiently access data from a variety of search perspectives.
It's a common mistake made by people that got too much OO design courses
to think that if they have enough RAM and CPU power, they can do just as
well as Oracle could or any DB.
> (The common English expression is "if you only have a hammer, everything
> looks like a nail". Is yours a direct translation of a French one?)
It's a mix of the french one and what little I remembered from the
english one ^_^
> and designing from the problem down rather than the database up
> is also a good thing.
Only if you make one-time use "kleenex" applications.
The problematic becomes quite different when your application will have
to live for many years and suit many customers.
Designing from the problem is a recipe for intimate mixing of data and
business logic, and pretty much guarantees that the application and its
data won't be able to evolve without *huge* costs (when it will be able
to evolve at all).
Good thing is that some of us can make a living out of replacing custom,
problem-based applications with standardized software ;)
Eric
Craig Stuntz [TeamB]
> Many people now use an object modelling tool like ECO or other OPF to
> generate a database to support an object model; there really is no
> need for an E-R tool as the entities and relationships are described
> in classes and interfaces; the database becomes a dumb datastore that
> holds simple tables, one per persistable class.
To me that's like saying we don't need a CPU view since we don't write
assembler very often. It makes little sense. Whether you design tables
directly or via a framework like ECO or your own homebrew system, a
database is still involved. We can't pretend it isn't there.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: http://learningtowhistle.blogspot.com
Joanna Carter [TeamB]
dans le message de news: 446c6912$1...@newsgroups.borland.com...
| To me that's like saying we don't need a CPU view since we don't write
| assembler very often. It makes little sense. Whether you design tables
| directly or via a framework like ECO or your own homebrew system, a
| database is still involved. We can't pretend it isn't there.
But ECO is designed to allow you pretend that the database isn't there, it
is responsible for generating the database and accessing it, not the
application code.
Craig Stuntz [TeamB]
> But ECO is designed to allow you pretend that the database isn't
> there,
I disagree. ECO lets you do many things, amongst them:
o Design the DB based on class design.
o Conversely, you can design classes based on the DB.
o Generate acceptable SQL in many if not most cases.
...but it does not let you pretend it isn't there. When you evolve a
schema you're certainly aware of the DB. When you go in and create
indices to enhance the performance of an app you're very aware of it.
When you monitor the SQL to optimize the app you're in the thick of it.
When you change the identifier columns from integers to GUIDs to
facilitate DB replication you're changing ECO's behavior for the
benefit of the DB. And if you write a Crystal Report which hits the DB
directly, you're doing nothing but database.
These ae not shortcomings of ECO in my opinion. As I said, you can no
more ignore the fact that ECO uses RDBMSs for persistence than you can
ignore the fact that Delphi code gets compiled into machine language.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Please read and follow Borland's rules for the user of their
server: http://support.borland.com/entry.jspa?externalID=293
Jim Cooper
> moreover in large databases it is sometimes simply unacceptable (due
> to inefficiency) to divide data and logic.
By definition data and logic are separated in an RDBMS. Having stored procs is
very definitely **not** having your logic in the same place as your data.
Jim Cooper
> The issue is more fundamentally that objects are neither data nor logic,
> but both at the same time, and the only separation you can have is a
> proactively introduced one: if you don't work for it, it won't be there.
The whole point of objects is not to separate them.
> while with OPFs, we've often bumped on unpenetrable walls...
Why? You can always access the data there too, surely? Or were you using a very
buggy OPF?
Jim Cooper
> FWIW one of the applications that couldn't scale was precisely a Java
> one using Hibernate ^_^
Then you were doing it wrong
Jim Cooper
> As I said, you can no
> more ignore the fact that ECO uses RDBMSs for persistence than you can
> ignore the fact that Delphi code gets compiled into machine language.
Good analogy. Almost all the time you *do* ignore the fact that Delphi code gets
compiled into machine language. I certainly never go and check that Delphi has
done it right :-)
Craig Stuntz [TeamB]
> > We can't pretend it isn't there.
>
> We can make it so that some people can pretend it isn't there.
Should we not have a CPU view in Delphi since some people pretend it
isn't there? I don't think so. I think that's equally true for an ERD
diagram. Especially considering that Together already does this in the
standalone version. It wouldn't be writing a new feature from scratch,
and I'll wager it would be more heavily used than the CPU view.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
Jim Cooper
> We can't pretend it isn't there.
We can make it so that some people can pretend it isn't there.
Jim Cooper
> RDBMS deal with more than <snip>
You've missed the point again. We only have them in the first place because of
the way we have to do persistent storage of large amounts of data. All those
other things you mention can be and are done with objects, and have been for
years (and I'm not talking about OODBMSs either)
> It's a common mistake made by people that got too much OO design courses
> to think that if they have enough RAM and CPU power, they can do just as
> well as Oracle could or any DB.
Again, you miss the point. We would not be using RDBMSs if we had enough
non-volatile RAM (the CPU is a bit irrelevant here). We Would be using different
techniques altogether.
> The problematic becomes quite different when your application will have
> to live for many years and suit many customers.
Precisely and exactly wrong!!!!!!!!!!!!! Those are the most important
applications of all to have maintainable code.
> Designing from the problem is a recipe for intimate mixing of data and
> business logic
That's called "object orientation" out here in the world.
> and pretty much guarantees that the application and its
> data won't be able to evolve without *huge* costs (when it will be able
> to evolve at all).
What *are* you talking about?
> Good thing is that some of us can make a living out of replacing custom,
> problem-based applications with standardized software ;)
Good thing that some of us can come in and repair the rubbish code some other
people write.
Jim Cooper
> Should we not have a CPU view in Delphi since some people pretend it
> isn't there? I don't think so.
I'd be quite happy not to have one.
> I think that's equally true for an ERD diagram.
Yes. I'd be quite happy not to have one of those either :-)
> I'll wager it would be more heavily used than the CPU view.
That is true. Almost everything is used more heavily than the CPU view :-)
Wayne Niddery [TeamB]
>
> Me too, but even on the most awfully structured databases, we've
> always been able to access the data, while with OPFs, we've often
> bumped on unpenetrable walls... getting access to the data was only
> possible through extra development from the part of the vendor with
> the OPF-based application.
I don't understand this part. Even if they only used the RDBMS as literally
a data dump, bad normalization, no constraints, etc, the data would still be
there and therefore accessible by other applications. The only way I can see
what you are describing is if the OPF saved data in some *proprietary*
format - and that I would agree is a very bad thing.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"Democracy, without the guarantee of liberty, is merely a method of
selecting tyrants." - Alan Nitikman
Eric Grange
Never said it was.
> Why? You can always access the data there too, surely?
For what is called OPF 'in general', IME no, data isn't readily
accessible for one or several of the top following reasons:
- data isn't stored in a DB, but in some other persistence
structures (like flat files, which additionnally may
not allow concurrent access)
- data is an SQL DB, but part of objects, or whole object
structures are stored as persistence streams
- objects and their fields are scattered in a soup of tables,
tables being related more to the type of data they store
than to objects or data entities (zillions of joins required,
after you've guessed them)
- location of a data fields depends on other fields or on
some other information that is built into the code
(or the internal metadata) of the application
- the same field can have multiple meaning, and store different
kind of information depending on the value other fields,
the rules of which being only known to the business logic code
- DB structure varies wildly between application versions, even minor
updates can completely change the mappings, table/field names
> Or were you using a very buggy OPF?
The issue with OPFs isn't about the one you use (which you can choose)
but about the ones the *other* applications use, which you have no
control off, which come in many flavours, often proprietary, often
language or development tool specific, and can be misused in a wild
variety of ways.
IME the issue about OPF isn't that they can't be pulled off cleanly, but
that they are easy to get wrong when design shortcuts are taken (and
there are almost always design shortcuts), and then, the end result is a
big proprietary "black box" that only the original OPF can access
"reliably".
Eric
Craig Stuntz [TeamB]
> > Should we not have a CPU view in Delphi since some people pretend it
> > isn't there? I don't think so.
>
> I'd be quite happy not to have one.
I wouldn't. So this may boil down to the fact that Delphi has many
features I never, ever use. Yet I wouldn't suggest removing them
because I realize that Delphi is not designed for me, personally. It is
certain that D2007 (or whatever it's called) will have more features
which I won't ever use. But it would be silly for me to suggest they're
not useful if I realize that they would be worthwhile for other people.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Everything You Need to Know About InterBase Character Sets:
http://blogs.teamb.com/craigstuntz/articles/403.aspx
Craig Stuntz [TeamB]
> Good analogy. Almost all the time you do ignore the fact that Delphi
> code gets compiled into machine language. I certainly never go and
> check that Delphi has done it right :-)
Absolutely. And yet any version of Delphi lacking this would be
completely crippled for the times when you need it.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Eric Grange
> a data dump, bad normalization, no constraints, etc, the data would still be
> there and therefore accessible by other applications. The only way I can see
> what you are describing is if the OPF saved data in some *proprietary*
> format - and that I would agree is a very bad thing.
When the RDBMS is used as data dump, this is IME what you're likely to
find, rather than neatly stored, neatly typed, neatly named fields.
As for the format, it doesn't need to be truly proprietary to be a pain,
working on a "clean" XML dump of an object structures, where there was a
decent amount of inheritance and abstraction is quite enough to get you
into trouble. Add in some binary streams, versionning, objects that
aren't fully cleaned up and carry around dead or duplicate members, and
the fun has truly begun.
Clean non-proprietary standard data formats wrapped around garbage OO
structures results in pretty garbage, but garbage still.
Yes, it's bad design, but bad design is quite common.
Eric
Eric Grange
Maybe *they* did it wrong, but since we trampled their application
running on an expensive server with ours running on a desktop PC,
they must have done it *very* wrong.
Methinks they rather lacked something as simple as the ability to index
megabytes of data arbitrarily and efficiently.
Eric
Bear
> standalone version. It wouldn't be writing a new feature from scratch,
Yes, and more important.
For developers that do database projects every week, this function will save
their a lot of time and a lot of money!
Why? because they can use this function:
0. Draw E-R diagram
1. Generate database schema script in seconds at any time
2. Generate Delphi project source code(forms, DB aware controls, datasets,
providers, fields, .....) in seconds at any time
But to developers those do not develop database application they do not need
this function.
Bear
"Craig Stuntz [TeamB]" <craig_...@nospam.please [a.k.a. acm.org]>
??????:446c7d73$1...@newsgroups.borland.com...
Jim Cooper
> Absolutely. And yet any version of Delphi lacking this would be
> completely crippled for the times when you need it.
Lacking what? Code generation or the CPU view?
Obviously Delphi would be crippled without machine code generation, but the CPU
view is of no value to me whatsoever.
Bear
> in a non-OO way is distinctly less powerful.
Yes. In fact I mean we do most things by OO but some times we need non-OO
things.
There is no need to do anything by OO. Delphi does not force us to do so.
Java force us to do so. In fact that make simple things complicated
sometimes.
> But the code that is generated is not as maintainable for non-trivial
> projects.
In fact the code will be thrown.
We just copy what we need to our real delphi project.
for example, there is a table : student.
The program will generate:
Student_DS:TDataSet in Datamodule
Student_DBGrid:TDBGrid on Form
Student_Nvg: TDBNavigator on form
etc.
We need copy it to our real delphi project.
If your database only have less than 10 tables, this way do not save your
time much.
But if you have 10-50 tables in your database, this way will save you a lot
of time on dragging and dropping, renaming etc.
Cheers,
Bear
"Jim Cooper" <jco...@tabdee.ltd.uk>
??????:446c2637$1...@newsgroups.borland.com...
>
>> 1. I think OO is just a tool, we should use it only when we can benefit
>> from it.
>
> Which is all the time. The power of Delphi comes from OO. Doing anything
> in a non-OO way is distinctly less powerful.
>
>> 2. There are still a lot of people "starting with the database design and
>> then connect data-aware controls directly to tables".
>
> And that works because of OO.
>
>
>> In fact, if the program know the E-R diagram, it only need one click to
>> generate the whole project source code with database module, forms,
>> navigation functions, and well named components.
>
> But the code that is generated is not as maintainable for non-trivial
> projects.
>
>
> The argument over whether OO is a better way to write software was decided
> decades ago. Not everyone seems to realise that, of course.
Jim Cooper
> But it would be silly for me to suggest they're
> not useful if I realize that they would be worthwhile
> for other people.
I only personally know one person for whom the CPU view is not completely
useless :-)
Many other dev tools get by perfectly well without one.
Jim Cooper
> Never said it was.
You have continually made comments about separating them.
> IME no, data isn't readily accessible
You said you bumped into "impenetrable walls". I would have to say that your
experience seems limited. Although in some cases it sounds like you've tried
some bizarre OPFs.
> IME the issue about OPF isn't that they can't be pulled off cleanly, but
> that they are easy to get wrong when design shortcuts are take
I have no idea what you're trying to say, sorry. There is crap design
everywhere, be it object oriented design or database design. Beyond that, I
don't get your point.
Jim Cooper
> Methinks they rather lacked something as simple as the ability to index
> megabytes of data arbitrarily and efficiently.
Then they did it wrong
Craig Stuntz [TeamB]
> Lacking what? Code generation or the CPU view?
The CPU view.
>
> Obviously Delphi would be crippled without machine code generation,
> but the CPU view is of no value to me whatsoever.
You are not the only user of Delphi.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better? Use QC!
http://qc.borland.com -- Vote for important issues
Eric Grange
> the CPU view is of no value to me whatsoever.
Interesting. Rare are the days when I don't use it, if only just to
check intermediate values in expressions or evaluations without having
to recompile the code.
Eric
Eric Grange
> You have continually made comments about separating them.
I have made comments about separating data design from the OO layer
design, which is quite different from saying that I desire separating
data and logic within the OO layer (which I do not).
> You said you bumped into "impenetrable walls". I would have to say that
> your experience seems limited.
Of course, and that back-handed comment here makes you look sooo
experimented... ^_^
>Although in some cases it sounds like you've tried some bizarre OPFs.
...alas you obviously jumped mid-discussion without bothering to read,
so I'll restate here: it's not OPFs I tried, it's OPFs I faced I had
trouble with, they were not things I wrote or used, but things we had to
try using as data sources, maintained by other, written by others,
designed by others, accessed by source code only known to others,
running on other's servers.
> [...] Beyond that, I don't get your point.
Might be that actually reading the posts before replying to them could
help with that ^_^
Eric
Wayne Niddery [TeamB]
>
> When the RDBMS is used as data dump, this is IME what you're likely to
> find, rather than neatly stored, neatly typed, neatly named fields.
Then I would consider that a lousy OPF and would never use it. I realize
that such exist, but no more or less than lousy databases exist or badly
designed software exists in general - it is not a justification to consider
OPFs, as such, to be the problem here.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"The two most abundant elements in the universe are hydrogen and
stupidity." - Harlan Ellison
Eric Grange
>> index megabytes of data arbitrarily and efficiently.
>
> Then they did it wrong
Which however true it might be doesn't change anything.
If everything was all right and done right in the world, the world would
be a very different place indeed. But it's not.
Eric
Eric Grange
> that such exist, but no more or less than lousy databases exist or badly
> designed software exists in general - it is not a justification to consider
> OPFs, as such, to be the problem here.
IMO it's a bit like saying that driving at 200 km/h in a city isn't a
problem and that the problem is just with bad drivers.
If you've got a DB-first approach, even with a DB gone wrong, data is
still there and accessible. With an OPF gone wrong, access to data
cannot be guaranteed anymore.
Eric
David Clegg
> Interesting. Rare are the days when I don't use it, if only just to
> check intermediate values in expressions or evaluations without
> having to recompile the code.
Like Jim, I've never really exploited its features, but comments from
yourself and others here have me wondering what I'm missing out on.
Perhaps you should write a BDN article explaining the benefits and
features of using the CPU view during a typical debugging session. I'd
certainly be interested in reading it, and I'm sure others here would
also benefit. Plus John Kaster will pay you for it, if he likes what he
sees. :-)
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"This donut has purple in the middle. Purple is a fruit!" - Homer
Simpson
Charles McAllister
> Like Jim, I've never really exploited its features, but comments from
> yourself and others here have me wondering what I'm missing out on.
> Perhaps you should write a BDN article explaining the benefits and
> features of using the CPU view during a typical debugging session. I'd
> certainly be interested in reading it, and I'm sure others here would
> also benefit. Plus John Kaster will pay you for it, if he likes what he
> sees. :-)
>
here's a use for it:
imagine someone pulls a prank on you and adds a call to Sleep() in your code, but way off past the right margin so you can't see it...
begin
DoSomething; { lots of spaces } Sleep(10000);
DoSomethingElse;
end;
...someone did this to me (mean trick BTW), and at the time i didn't know to check the CPU window as i was debugging through it. probably would have caught it a lot faster.
David Clegg
> imagine someone pulls a prank on you and adds a call to Sleep() in
> your code, but way off past the right margin so you can't see it...
Hehe! I like that :-)
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"Do I know what rhetorical means?" - Homer Simpson
vavan
wrote:
>By definition data and logic are separated in an RDBMS. Having stored procs is
>very definitely **not** having your logic in the same place as your data.
believe it or not but usually using native stored procedures
exploiting vendor-optimized engine and executing within the same place
where data is (in dbms) is the most efficient way of handling data
--
Vladimir Ulchenko aka vavan
Eric Grange
> yourself and others here have me wondering what I'm missing out on.
Some understanding of ASM is required, but there are some situations
where it can be used without an extensive knowledge. The most typical
"simple" case I use it is when there is code like
Object.Thing.Stuff.Blah
and you get some access violation because one of these returns a nil,
but the debugger doesn't want to evaluate "Object.Thing" f.i. Without
the CPU view, you're stuck with introducing intermediate variables (may
not be possible, f.i. if you're dealing with VCL code) or indirectly
worming your way to the objects involved (time consuming).
But if you bring up CPU view, the ASM will look like
..whatever...
call Object.Thing
..whatever..
call Thing.Stuff
..whatever..
call Stuff.Blah
return value of all these calls are placed in EAX, so just step over the
calls and look at EAX, and you'll know which of the getter is returning
a nil without getting into "step into" hell (particularly if debug DCUs
are checked and you have dynamic methods involved...). You can also have
a look at the intermediate objects, f.i. with a TObject(eax).ClassName
If you don't have getters but properties with direct read, you'll have a
mov instead of a call... but things become less straightforward.
Similar approach can be applied for math/conditionnal expressions, or
parameter passing to a function in those circumstances when the debugger
doesn't want to evaluate them... but you really need to be fluent in ASM
then.
In the end though, if you understand enough of ASM, you can identify
pretty much all crashes in the first debugger pass, which can be quite
invaluable if the crash happens only after going through several screens
or some lengthy sequence of operations.
> Perhaps you should write a BDN article explaining the benefits and
> features of using the CPU view during a typical debugging session.
Except for the getters-that-return-an-object trick like above, knowledge
of ASM is required, I'm not sure there would be much of an audience...
as those that understand enough of ASM are likely to already be using
the CPU view.
Eric
David Clegg
> Some understanding of ASM is required,
exit;
> but there are some situations
> where it can be used without an extensive knowledge. The most typical
> "simple" case I use it is when there is code like
Ah, ok. Thanks for the tip.
> Except for the getters-that-return-an-object trick like above,
> knowledge of ASM is required, I'm not sure there would be much of an
> audience... as those that understand enough of ASM are likely to
> already be using the CPU view.
Fair enough. FWIW, learning assembler has been on my TODO for a while,
but sits below learning C++, which I've also still not done. At least
I've bought a book on the latter though. :-)
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"We live in a society of laws. Why do you think I took you to all those
Police Academy movies? For fun? Well, I didn’t hear anybody laughin’,
did you?" - Homer Simpson
Joanna Carter [TeamB]
0moq62td6g4v1lfqc...@4ax.com...
| believe it or not but usually using native stored procedures
| exploiting vendor-optimized engine and executing within the same place
| where data is (in dbms) is the most efficient way of handling data
I think that one thing that is missing in this whole RDBMS vs OO debate is
the realisation that an RDBMS is simply a program that reads data from disk
into memory, manipulates it and then writes it back.
It is not "magic" and it is not necesarily better than any of us taking data
from disk into our programs, manipulating it and then writing it back. It is
just that we regard the RDBMS as a black box which we can trust. (??)
Certainly the good RDBMSs are usually capable of fairly optimal processing
of requests but how does that preclude well written OPFs from being
optimised ?
As has been noted before, we are not yet in the position of having a good,
cheap, reliable OODB, so the nearest some of have got is to use a very
efficient RDBMS to write the data to disk whilst using the OPF to translate
objects and lists of objects into rows in database tables.
The reason why stored procs in a database are so efficient is that the
compiler inside the database has been custom written to take your SQL
statements and apply it in the most efficient manner that the database
authors could work out.
Nonetheless, remember that all a RDBMS is is another program that reads data
from disk, processes it and then writes it back.
Now, as to the matter of using business objects in code rather than database
components, think about this :
Ever since Delphi 1 we have had a TDataset or TQuery style of component that
we dropped on a form and talked to in code.
Question - what is a TDataset ?
Answer - it is an object that contains a data buffer and a set of methods
that act on that data buffer. The TDataset connects to a table/result set in
a database and populates the buffer on an "as required" basis. This then
allows us to browse a "table" of "records".
Question - how is using a TDataset object, that contains data read in from a
database and code that acts on it, any different from using a business
object that contains data read in from a database (through an OPF) and code
that acts on it ? Surely, there is as much chance for errors when trying to
update tables from the buffers in a TDataset object as there is writing back
the data in a business object ?
Answer - The only real difference between most people's concept of an OPF
and a RDBMS is that they don't realise that a well written OPF can be just
as optimal at managing code against data as can a RDBMS.
The only difference between an OPF and an OODB is that we tend to use a
RDBMS as a means of reading/writing the data from/to disk, whereas a true
OODB would have its own on-disk data format.
There is nothing to stop OPF writers from using/creating stored procs for
the DB to use. Business logic present in the object domain can be mapped to
existing SPs or SPs can be written on the fly by the OPF.
e.g.
public class SalesLedger
{
public void RetrieveProductQuantitiesForCustomer(Customer customer)
{
OPF.RetrieveQuery("ProductQtyForCustomer"); // maps to stored proc
}
}
public class SalesLedger
{
public void RetrieveProductQuantitiesForCustomer(Customer customer)
{
string orderCondition = "Customer = " + Customer.ID;
List<Order> orders = OPF.RetrieveList(typeof(Order), orderCondition);
...
foreach (Order order in orders)
... // build up list of Product/quantity objects
}
}
The OPF can create code that knows the underlying data just as intimately as
the stored procs in a RDBMS, after all the RDBMS still has to read the data
from disk into its own "working memory" before it can manipulate it and
there are still opportunities for reconciliation errors whilst a stored proc
is being executed, if another user touches the same data at the same time. I
could just as well use a pessimistic locking strategy to access the DB from
the OPF and prevent other users from updating the DB whilst my OO code is
executing (not nice, but possible).
If you think that getting data out of an OPF is difficult, then consider the
possibility that an OPF can return a list of objects that contain lists of
values for any given type name.
e.g.
public class Field
{
public string Name...
public object Value...
}
public class Record
{
public Field this[string fieldName]...
}
public class Table
{
public string Name...
public Record this[int index]...
}
public class OPF
{
public Table GetQuery(string query)
{
...
}
public Table GetTable(string name)
{
...
}
}
Now you have the basics of a generic object structure that can retrieve any
fields of any records of any table, given the table name or a query string.
Don't forget a RDBMS is just a black box around someone else's program; you
can always think "outside the box" :-)
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
Joanna Carter [TeamB]
446d...@newsgroups.borland.com...
| Some understanding of ASM is required
Ok, tilt !!!
My personal attitude is that, if I knew I had to learn assembler to use a
debugging tool, then I never would have bothered to move to Delphi. The
whole attraction of a good IDE like Delphi is that I don't have to learn
assembler to write and debug programs.
My suspicion is that, although this feature is undeniably very useful for
ASM geeks and hackers, most people doing RAD development don't even know how
assembler works.
I have occasionally looked at the CPU window when it pops up, scratched my
head, closed it and introduced temporary variables, etc, then re-run the
program again watching the values returned by the debugger.
BTW, yes I did do a bit of assembler at uni' but I never did get the hang of
which registers did what. I must admit I still have a hankering to get a
grip on it, but I really can't make as much money out of it as I can
learning about the massive .NET framework.
Eric Grange
> but sits below learning C++, which I've also still not done. At least
> I've bought a book on the latter though. :-)
Learned ASM back in the Z80 days, and it's like riding a bicycle, you
never forget ;)
Eric
David Clegg
> Learned ASM back in the Z80 days, and it's like riding a bicycle, you
> never forget ;)
Yeah, I often wish I'd arrived to where I am today by that route too.
But coming to programming comparatively late in my career, I missed out
on learning ASM and other disciplines which I feel would make me in
many ways a better programmer.
After all, having a better understanding of how things work under the
covers has to be helpful in ensuring you're choosing the most optimal
solution in a discipline where there are often many ways to solve the
problem at hand. Retrofitting this knowledge would be useful, but still
not quite the same.
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"I don't have to be careful. I've got a gun!" - Homer Simpson
Jim Cooper
> There is no need to do anything by OO.
Indeed. We could do everything with toggle switches. It would however, be a dumb
idea.
> Delphi does not force us to do so.
Something of a weakness, I think. It is one of the reasons many Delphi
programmers do not understand OO. Quite a lot of Delphi code I see is VB code
written in Pascal.
> We just copy what we need to our real delphi project.
I think you have missed my point.
> The program will generate:
And I don't think you should write code that way, whether or not you generate it
automatically.
> But if you have 10-50 tables in your database, this way will save you a lot
> of time on dragging and dropping, renaming etc.
It will cost you an enormous amount of time with maintenance though.
Jim Cooper
> Interesting. Rare are the days when I don't use it, if only just to
> check intermediate values in expressions or evaluations without having
> to recompile the code.
Is there some reason you like to do things the hard way? :-)
There are much nicer ways to debug your code.
Jim Cooper
> You are not the only user of Delphi.
Indeed not. As I have already said though, the CPU view is completely useless to
almost everyone I know. It would in no way "cripple" Delphi if it did not have
one. Other dev tools get on just fine without one.
Jim Cooper
> comments from yourself and others here have me wondering
> what I'm missing out on.
Not much. I've seen it used, and it is of no value in code that I write myself,
since I don't write code that bad :-) It can be used by someone who knows what
they're doing in certain situations, but when I've come across them that I get
the client to hire Brian Long directly :-)
Jim Cooper
> I missed out on learning ASM and other disciplines which I feel
> would make me in many ways a better programmer.
Hmmm. My experience suggests the opposite is true. Most of the ASM fluent people
I've come across are not very good at programming in the large (as this thread
might be indicating).
ASM knowledge is useful (even essential) in some corner cases, but is almost
completely useless for most people's day-to-day work.
> After all, having a better understanding of how things work under the
> covers has to be helpful in ensuring you're choosing the most optimal
> solution in a discipline where there are often many ways to solve the
> problem at hand.
Nope, it doesn't. Trivial and obvious cases aside, programmers are notoriously
bad at picking code bottlenecks from inspection of code. ASM addicts are often
the most vociferous at disagreeing with this :-) They're still wrong.
Profilers are the way to identify where optimisation needs to be done, and to
measure the difference between different solutions.
I have never needed to write ASM code in a production system. The more things
move on, the less likely it is that I will ever need to. Should that ever be
necessary, it's best to get in an expert, IMO.
Oliver Townshend
> never forget ;)
Well I can still ride a bike, but never enjoyed ASM. I suppose I can still
do it though, but I've always find the CPU window useless because you have
to step through far too much to see anything. And I program in Delphi, so
what would the CPU window tell me about my code, except how its been
compiled.
Oliver Townshend
Jim Cooper
> I have made comments about separating data design from the OO layer
> design
OK, that's clearer. Your earlier comments did not read that way to me.
In that case it strikes me that there are two approaches. One is the
"traditional" Delphi data-aware controls way of doing things, where you design
the data to match the problem domain. This typically means you end up with a not
particularly OO solution (you only have an OO view of tables, columns, result
sets etc, not of the problem domain). Data storage is relatively
straight-forward, but you get more inflexible and difficult to maintain code.
The other is to model the problem domain in an OO way, and then try and store
the resulting objects. This typically results is a more sophisticated and
flexible model, but makes data storage more complicated.
IME the second solution is better over the longer term for most projects.
Also IME not all OPFs are created equal, and they are not as general purpose as
their creators would like to think.
> Of course, and that back-handed comment here makes you look sooo
> experimented... ^_^
In the case of Delphi OPFs, then yes I have tried all the ones I could find.
From your comments I would think I could identify some you had which problem with.
Dissatisfaction with the existing solutions is why I have written my own OPFs. I
was able to tailor them to my requirements.
> ...alas you obviously jumped mid-discussion without bothering to read,
Since I have read the whole discussion, your "obvious" conclusion is completely
wrong.
> Might be that actually reading the posts before replying to them could
> help with that ^_^
Since I clearly always do that, you might want to consider that your point is
not being made as well as it might be.
vavan
<joa...@not.for.spam> wrote:
>the realisation that an RDBMS is simply a program that reads data from disk
>into memory, manipulates it and then writes it back.
>It is not "magic" and it is not necesarily better than any of us taking data
oh yeah, please go and try to say that to all those oracle developers
who wasted uselessly all those years trying to polish their dbms
engine :)
>of requests but how does that preclude well written OPFs from being
>optimised ?
it doesn't preclude at all. but this _enormous_ job has to be done,
otherwise you'll probably get "well written" OPF but when things
crosses some threshold of complexity you may realize that it isn't as
"optimised" as you thought before :)
>Nonetheless, remember that all a RDBMS is is another program that reads data
>from disk, processes it and then writes it back.
production-level RDBMS is much more than that, you know, it is a very
complex system of different layers and components which simply cannot
be implemented by a single developer
>database and code that acts on it, any different from using a business
>object that contains data read in from a database (through an OPF) and code
>that acts on it ? Surely, there is as much chance for errors when trying to
there's not much difference if your OPF is flexible enough to allow me
to control which stored procedures of back-end dbms I desire to invoke
in order to react on changes introduced by end-user (similar to
multi-tier approach used in midas)
>There is nothing to stop OPF writers from using/creating stored procs for
>the DB to use. Business logic present in the object domain can be mapped to
>existing SPs or SPs can be written on the fly by the OPF.
then why you told that: "some of the business logic is also placed in
the the DB. This then takes us back to the bad old days where we have
data in one place and functionality in another" ? you know, old good
proven dbms never grow obsolete :)
>the stored procs in a RDBMS, after all the RDBMS still has to read the data
>from disk into its own "working memory" before it can manipulate it and
yes, but there's no overhead of passing that data (which might be
large enough) onto additional logic layer, all business logic could be
implemented right where the data is i.e. in dbms itself
>there are still opportunities for reconciliation errors whilst a stored proc
>is being executed, if another user touches the same data at the same time. I
it is completely orthogonal issue
>If you think that getting data out of an OPF is difficult, then consider the
let me clarify: I don't think so, moreover I'd like to see (and
probably use) OPF which is as efficient as I need to for my goals.
unfortunately I don't think it is always possible
>public class Field
>public class Record
>public class Table
>Now you have the basics of a generic object structure that can retrieve any
>fields of any records of any table, given the table name or a query string.
ok, but why to introduce it at all if there's already all needed
functionality implemented in frameworks similar to midas? you already
can map every object onto TDataSet level
>Don't forget a RDBMS is just a black box around someone else's program; you
>can always think "outside the box" :-)
I'm grateful to dbms vendors (such as oracle) that I can simply
implement all needed business logic handling gigabytes of data
everyday "outside the box" without additional difficulties of
reimplementing my own wheel :)
Jim Cooper
> With an OPF gone wrong, access to data cannot be guaranteed anymore.
You keep saying that, without any apparent justification. Can you give an
example of what you mean?
Jim Cooper
> be a very different place indeed.
Indeed. But saying that because someone designed or implemented some OO solution
badly you should never use an OPF is a flawed argument.
I've seen really, really crappy Delphi code, far worse than the worst C or BASIC
code I've seen. I've seen very poor database designs.
Does that mean Delphi or RDBMSs should not be used?
Of course not.
Jim Cooper
> believe it or not but usually using native stored procedures
> exploiting vendor-optimized engine and executing within the same place
> where data is (in dbms) is the most efficient way of handling data
That's bollocks for at least two reasons.
Firstly, I'll repeat that having stored procs in a database is **not** having
your business logic and data in the same place. As has already been noted in
this thread, that is like saying global variables and standalone procedures in
the same program means your data and related business logic are in the same
place. If you do not understand this point, then you need to read up a little on
encapsulation, and likely other OO principles.
Secondly, whether or not it is the "most efficient" way of handling data depends
entirely on what you are doing with that data. It is almost always better to
have all the data in memory, surely, since that is orders of magnitude faster
than hard disk access?
Craig Stuntz [TeamB]
> Eric Grange wrote:
>
> > Some understanding of ASM is required,
>
> exit;
David, I happen to think that you're smart enough to figure a few
things out with a good hard look (your taste in music notwithstanding).
One of the things about ASM is that for all the acronyms it's actually
a pretty simple language. As Eric correctly points out, some of the
stuff in the CPU view (e.g., CALL) is quite easy to understand even for
someone with no knowledge of ASM at all.
Anyway, here's a getting started article:
http://www.blong.com/Conferences/DCon2000/Debugging/Debugging.htm
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
How to ask questions the smart way:
http://www.catb.org/~esr/faqs/smart-questions.html
Craig Stuntz [TeamB]
> > Interesting. Rare are the days when I don't use it, if only just to
> > check intermediate values in expressions or evaluations without
> > having to recompile the code.
>
> Is there some reason you like to do things the hard way? :-)
>
> There are much nicer ways to debug your code.
"Nicer" is certainly a POV term here; I personally find it a pain to
have to shut down, recompile, and restart an app to introduce an
intermediate variable (using Eric's example).
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com
Jim Cooper
> you know, old good proven dbms never grow obsolete :)
Yeah, right.
In an ideal world, nothing would be done in stored procs. The world is not
ideal. QED.
> all business logic could be
> implemented right where the data is i.e. in dbms itself
The business logic and data are in completely different places. The data is in
tables, and the business logic is in stored procs. Compare this with an object
to see what is meant here.
I don't think you have a grasp of what an OPF actually is.
A paper and a very simple example explaining basic concepts is here:
http://www.tabdee.ltd.uk/Software/Papers/BuildingAnOPF/BuildingAnOPF.html
Jim Cooper
> I personally find it a pain to
> have to shut down, recompile, and restart an app to introduce an
> intermediate variable (using Eric's example).
Well, two questions.
Why are you not just using the normal debugging windows to find this information
out?
Why are you not finding this out in unit tests? :-)
vavan
wrote:
>That's bollocks for at least two reasons.
please work out your vocabulary
>Firstly, I'll repeat that having stored procs in a database is **not** having
>your business logic and data in the same place. As has already been noted in
I'm not going to waste my time argueing about terminology, but you
really should understand that you simply cannot go any closer to data
than native stored procedures executing within dbms
>this thread, that is like saying global variables and standalone procedures in
I don't find your analogy any appropriate
>encapsulation, and likely other OO principles.
oh please don't make me laugh :)
>Secondly, whether or not it is the "most efficient" way of handling data depends
>entirely on what you are doing with that data. It is almost always better to
completely agreed, one cannot insure himself from bad design, poor
programming etc. by simple using of SP instead of other mechanism (no
matter OPF or smth else). but that wasn't my point
>have all the data in memory, surely, since that is orders of magnitude faster
>than hard disk access?
if only all databases could completely fit into boundless RAM of some
hypothetical computer without the risk of loosing/corrupting it, than
probably your argument would be perfectly fine :)
Craig Stuntz [TeamB]
> Why are you not just using the normal debugging windows to find this
> information out?
Huh? How would you do that using Eric's example? (I presume by "normal
debugging windows" you in fact mean "debugging windows other than the
CPU window.") Especially if, for example, one of the classes in the
chain is a VCL class and you've compiled w/out debug DCUs.
> Why are you not finding this out in unit tests? :-)
This may in fact indicate that a unit test is necessary. (Or it may
not; the circumstance described is pretty broad.) I don't know about
you, but I don't always get my tests right the first time (in fact, I'd
say I get them wrong at more or less the same rate I get other code
wrong). Plus I have scads of code which predates DUnit. But even if I
determine that, yes, in fact I should have caught this with a unit
test, the fact that I am even asking the question indicates that I
don't have the right test yet. Yes, I could shut down, re-write,
re-compile, and re-run, but now I've lost my flow and lost the context
of the bug, which may or may not be easy to recreate.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Useful articles about InterBase development:
http://blogs.teamb.com/craigstuntz/category/21.aspx
Jim Cooper
> please work out your vocabulary
Insert the phrase of your choice meaning "that's utterly and completely wrong" then.
> I'm not going to waste my time argueing about terminology, but you
> really should understand that you simply cannot go any closer to data
> than native stored procedures executing within dbms
You are still completely missing the point. Do you understand what is meant by
"encapsulation" in the object oriented sense of the word?
You can most certainly get data and business logic much, much closer, since they
are in fact completely separate things in an RDBMS.
> I don't find your analogy any appropriate
That's because you do not understand what I'm trying to say.
> if only all databases could completely fit into boundless RAM
You are confusing data with database, for starters.
Plenty of data never goes anywhere near a database.
vavan
wrote:
>In an ideal world, nothing would be done in stored procs. The world is not
>ideal. QED.
that's exactly my point, the world is not ideal and OOP isn't the
silver bullet, it's just another methodology amongst the others
>The business logic and data are in completely different places. The data is in
by repeating this you don't go any further
>I don't think you have a grasp of what an OPF actually is.
perhaps you would be quite surprised to know that I'm somewhat
familiar with Martin Fowler, Scott Ambler (etc.) papers :)
p.s. you know I came across this thread by accident (I usually visit
only cpp groups on borland newsserver) so due to other tasks I
probably have to leave for now, sorry
David Clegg
> David, I happen to think that you're smart enough to figure a few
> things out with a good hard look
<blush>
> (your taste in music
> notwithstanding).
Mate, you do *not* want to draw me into *that* argument :-)
> Anyway, here's a getting started article:
>
> http://www.blong.com/Conferences/DCon2000/Debugging/Debugging.htm
Thanks Craig, that looks like a great starting point.
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"Aw, Dad, you've done a lot of great things, but you're a very old man,
and old people are useless." - Homer Simpson
Joanna Carter [TeamB]
hhcr629n3mlg4cod4...@4ax.com...
| I'm not going to waste my time argueing about terminology, but you
| really should understand that you simply cannot go any closer to data
| than native stored procedures executing within dbms
Yes you can!! Code in a class operating on the data within that class, all
in the same small area of memory is closer than having the DB read the data
from disk into memory in order to execute the stored proc which is also
stored on disk and has to be read into memory before execution.
| >this thread, that is like saying global variables and standalone
procedures in
|
| I don't find your analogy any appropriate
Certainly, it is relevant, stored procs are in one part of the database,
tables are in another, tables are global to the whole database, otherwise
only certain SPs would be able to see them.
| if only all databases could completely fit into boundless RAM of some
| hypothetical computer without the risk of loosing/corrupting it, than
| probably your argument would be perfectly fine :)
That is exactly Jim's and my point!!! If we had perfectly reliable,
multi-terabyte, non-volatile memory, then we really wouldn't need RDBMSs.
Take a look at Prevayler, it comes close; the only real difference is that
it loads *everything* into memory on startup and then saves it *all* at
closedown. Combined with a decent UPS, this is about as close as you can get
to always on, non RDBMS storage. ( not accounting for Windows of course :-))
Bear
>
> ..whatever...
> call Object.Thing
> ..whatever..
> call Thing.Stuff
> ..whatever..
> call Stuff.Blah
Yes, I used CPU view to find the function time sometimes too.
Bear
Joanna Carter [TeamB]
| oh yeah, please go and try to say that to all those oracle developers
| who wasted uselessly all those years trying to polish their dbms
| engine :)
Which doesn't explain why it took a team of Oracle engineers three weeks to
get an, already written, database up and running on one site that I was
involved with. There was nothing wrong with the database, simply configuring
the server was enough of a problem.
| production-level RDBMS is much more than that, you know, it is a very
| complex system of different layers and components which simply cannot
| be implemented by a single developer
OPFs are not limited to those written by a single developer. If enough of us
OPF types could justify the cost, we could quite easily implement any level
of complexity. Perhaps if Oraclze threw as much money at OODBs as they
continue to do at RDBs, we wouldn't be having this argu^H^H^H^Hdiscussion
:-)
| then why you told that: "some of the business logic is also placed in
| the the DB. This then takes us back to the bad old days where we have
| data in one place and functionality in another" ? you know, old good
| proven dbms never grow obsolete :)
I have never espoused putting business logic in the database; it is RDB
die-hards that insist on us OO types having to do that.
| yes, but there's no overhead of passing that data (which might be
| large enough) onto additional logic layer, all business logic could be
| implemented right where the data is i.e. in dbms itself
Likewise, once the data is read from disk into business objects, there is no
further overhead in executing code in those same business objects.
| let me clarify: I don't think so, moreover I'd like to see (and
| probably use) OPF which is as efficient as I need to for my goals.
| unfortunately I don't think it is always possible
Pay me, Jim and Bob enough and you shall see it :-))
| ok, but why to introduce it at all if there's already all needed
| functionality implemented in frameworks similar to midas? you already
| can map every object onto TDataSet level
Because Midas and TDataset is not as efficient as having business objects
that don't have to access the data in their fields by name indexes as is
common in generic database component technologies. Also Midas is an IPC,
therefore adding extra overhead to the IPC overhead of talking to the DB
directly.
| I'm grateful to dbms vendors (such as oracle) that I can simply
| implement all needed business logic handling gigabytes of data
| everyday "outside the box" without additional difficulties of
| reimplementing my own wheel :)
Uh uh, you are not handling data "outside the box", you are limiting
yourself to what those guys at Oracle decided to put in the box.
Craig Stuntz [TeamB]
> I think that one thing that is missing in this whole RDBMS vs OO
> debate is the realisation that an RDBMS is simply a program that
> reads data from disk into memory, manipulates it and then writes it
> back.
Er, no. That isn't what RDBMSs do. If that's what you need, you can
use XML files for storage. That's not even a simplification of what an
RDBMS does.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Joanna Carter [TeamB]
dans le message de news: 446dc175$1...@newsgroups.borland.com...
| Er, no. That isn't what RDBMSs do. If that's what you need, you can
| use XML files for storage. That's not even a simplification of what an
| RDBMS does.
I think you misread my badly worded statement :-)
What I was implying was that the DB reads data from disk into its own
executable memory area and then manipulates it (using SPs, etc) there before
writing it back to disk. Most programs that we write can do just the same by
designing our own on-disk structures and indexing methodologies. The
difference is the RDBMS is a black box that can save us the effort, if it
suits our needs; it doesn't really suit mine, but until we can get a true
OODB, OPFs will have to talk to RDBs :-(
Eric Grange
> ASM geeks and hackers, most people doing RAD development don't even know how
> assembler works.
Yep, just like you need to know how a car works to drive a car in casual
situations. Though if you don't want to shorten the engine's life
through mishandling you'll need some understanding... same goes for
properly handling a car in dangerous situations like heavy rain ;)
> [...] but I really can't make as much money out of it as I can
> learning about the massive .NET framework.
Money-wise, that's a different market, having rare skills helps command
a premium and/or gives the freedom to be picky about the job.
> learning about the massive .NET framework.
I'd rather work on the the high-level design phase on one hand, and the
critical sections of the code on the other, rather than on the boring,
grunt-level stuff in between. But that's just me. ^_^
Eric
Craig Stuntz [TeamB]
Ditto for RDBMSs. And OODBMSs have been floundering as a conceptually
interesting idea which doesn't really work so well in the real world
for the same timeframe. Interesting, no? Why do you think that is?
Me, I think it's because people who say they want an OODBMS really
want some sort of dumb-but-somehow-magical system to save the state of
their classes when the computer's power is off with maybe a doodad here
or there to get to the instance you want to read faster. And the notion
works more or less OK as long as no two people ever use the thing
concurrently. Much of the so-called "impedance mismatch," I think,
comes from the fact that OO systems frequently don't address (and
certailny almost never mandate) things which RDBMSs define / conform to
quite formally, like concurrency control and set theory.
In short, I dispute the implication that RDBMSs are what we have to
put up with just because nobody has managed to write a functional
OODBMS. I think the reason for the infancy-despite-its-age of the
OODBMS market is because vital RDBMS *features* have typically been
seen by OODBMS-wishers as liabilities, and until they get over that
hump the thing they wish for isn't going to be built. In particular,
it's going to require some far-reaching changes to OO frameworks to
support concurrency, like making distributed transactions mandatory for
shared instances at the very least.
That said, anyone who wants real concurrency control and massive
scalability today is using an RDBMS no matter what their code looks
like. OO frameworks do not give us the tools to manage all parts of an
RDBMS effectively, so we use ERDs and other things no matter how we
design our data.
--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Please read and follow Borland's rules for the user of their
server: http://support.borland.com/entry.jspa?externalID=293
Eric Grange
> myself, since I don't write code that bad :-)
Speaking of which I would be interested to see code you write.
I mean it's all grand cheap to brag here, but are there any sizeable
portions you could show us these superior code writing skills?
Found little samples via google like there
http://www.richplum.co.uk/downloads/index.asp
and I was quite underwhelmed. Didn't look like the pure and clean coding
style as you're bragging out.
Anything more sizeable we could have a look at?
Eric
Eric Grange
> information out?
Surprising question, maybe you haven't used the debugger recently?
Shortest possible example:
- create a new project
- add the following method to the form
function TForm1.Getter : TForm1;
begin
Result:=Self;
end;
- add a button, and in its OnClick handler, place
Getter.Caption:='hello';
Now place a breakpoint on that line, compile, run, and ask the value of
'Getter' to the debugger.
Use F7 to "step into" you said? Assuming we disreguard the issue you'll
have with evaluating "Result" under D7 as "too cheap", here is even more
fun coming your way:
- make Getter a dynamic method
- turn on debug DCUs, recompile
- run, reach the breakpoint
- now "step into".
Yes. Good old barrel'o fun.
And don't come telling me that good design shouldn't involve "dynamic"
methods, go tell that to the VCL designers.
> Why are you not finding this out in unit tests? :-)
You mean to say that you never have any crash or bug in your
applications at runtime because all the possible failures are convered
by unit tests?
Ok! Deal. I take the challenge. Post the application. :)
Eric
Eric Grange
No, it's not flawed, you're just missing the point: even in the most
flawed RDBMS that I've ever encountered, the data was still there and
available. And that was the case for the worst RDBMS you've ever
encountered too (yes it was, if not, feel free to prove me wrong by
posting the DB).
Even in a moderately flawed OPF, the data isn't guaranteed to be
accessible anymore. Actually, even in a "perfect" OPF, the data isn't
guaranteed to be accessible to the outside, and for that to happen, they
merely have to be using a proprietary data repository, and not be
providing the tools to migrate it to a standard repository.
Besides you're (once again) trying to misrepresent what I said, either
through malice or ignorance.
My point isn't that you should not use an OPF, but that you should not
design the data structures from the OPF, but instead design the data
first, and have the OPF and OO layers access that, as a way to
*guarantee* the accessibility of the data.
Eric
Jan Derk
> > I'm not going to waste my time argueing about terminology, but you
> > really should understand that you simply cannot go any closer to
> > data than native stored procedures executing within dbms
> Yes you can!! Code in a class operating on the data within that
> class, all in the same small area of memory is closer than having the
> DB read the data from disk into memory in order to execute the stored
> proc which is also stored on disk and has to be read into memory
> before execution.
Brilliant idea! Just load your complete database into memory and it
will speed up things tremendously. Why did no database company think of
that!
Wow, you should patent the idea and then tell it to Google. They will
be so happy to see their services speed up by an order of magnitude.
> Take a look at Prevayler, it comes close; the only real
> difference is that it loads everything into memory on startup and
> then saves it all at closedown. Combined with a decent UPS, this is
> about as close as you can get to always on, non RDBMS storage. ( not
> accounting for Windows of course :-))
Shudder...
Let me ask a serious question: Are you an academic?
Jan Derk
Craig Stuntz [TeamB]
> That is exactly Jim's and my point!!! If we had perfectly reliable,
> multi-terabyte, non-volatile memory, then we really wouldn't need
> RDBMSs. Take a look at Prevayler, it comes close; the only real
> difference is that it loads everything into memory on startup and
> then saves it all at closedown
Prevayler's designers have demonstrated profound misunderstanding of
what RDBMSs do. This has been discussed in this group in the past; I'll
not repeat it here as you can easily find it via Google.
It is *precisely* this attitude which has caused the complete failure
to produce a viable OODBMS, I think. I don't believe such a beast will
ever come from someone who doesn't understand what an RDBMS does.
Eric Grange
> an example of what you mean?
Most deadly one: objects -for which you don't have the source- that are
streamed and placed in a blob/clob, ala bitmap, except it's not using a
standard format - and why should it be, the OPF application is perfectly
happy with it, it's super-convenient and super-fast for it to store
things that way...
Listed other variations in another post in this thread.
Eric