Re: SQL
- From: "frebe" <fredrik_bertilsson@xxxxxxxxxxx>
- Date: 25 Jan 2006 03:10:13 -0800
> Transactions, as offered by RDBMS:es, are limited to the data stored witin the RDBMS,
> so that if you want to use its transaction capability, you need to store the
> appropriate data in the RDBMS.
Many RDBMS vendors supports distributed transactions (like XA). Other
resources, such as messages may also be part of the same transaction.
The component that controls the transaction is indeed outside the
RDBMS, but the RDBMS is able to participate in transaction, in opposite
to a file system.
> but if you wanted to use one or maybe two of them _without_ wanting to use its
> data storage model
Which other data storage model do you have in mind? XML files? Flat
files? In most enterprise scenarios these kind of low-level storage
models is simply not enough.
> both queries, transactions and referential integrity
> are just as applicable to persistent as to non-persistent data,
Exactly my point. You need queries even if you don't need persistence.
A RDBMS may be useful even if you don't have any persistence needs.
> So, if all you want is transactions, an RDBMS probably shouldn't be the first
> place to go.
So, where should I go?
> What precisely is your definition of an 'enterprise application'?
I don't have a clear definition. I use the word to make people
understand that I am not talking about MP3 players, FTP clients etc. I
am mainly talking about applications for accounting, logistics
management, production control, etc.
> but from your statement above it sounds like you would characterise enterprise
> applications as using databases _not_ for incoming our outgoing data, but
> _mainly_ for transient data used only in the process of whatever they are
> doing?
An average enterprise application need persistence. But they also need
a lot of features provided by a RDBMS that is not related to
persistence (such as quieries).
> So, databases were used to overcome the deficiencies in COBOL's support
> for data structures?
No, the creators of COBOL did not make any advanced collection features
in the language simply because it was not necessary. A high-level
language was supposed to not handle data in a low-level way. Collection
handling was supposed to be done in a high-level way (SQL).
>>If you look at enterprise applications outside the OO world, you will
>>find that they heavily use embedded SQL.
>Please, give me some more specific pointers.
Do you doubt that pre-OO applications make heavy use of embedded SQL?
Look at the Oracle products Pro*C or Pro*COBOL for example. The
corresponing product for java, SQLJ, has gain very little attention
because the OO world rejects the use of embedded SQL.
> If you package up your data structures appropriately and offer suitable
> operations on them, you can end up with a system that becomes similarly
> easy to use as a database,
Lets say i want to find every customer order from a customer located in
a given city I use this select statement:
select *
from order
join customer on order.customerid=customer.id
where customer.city=?
How would your code look like?
> It may well be that even an in-memory RDBMS might
> be too slow for your application.
But not very likely for enterprise applications. The most of time
overhead with using a RDBMS is in the inter-process and network
communication. Using stored procedures gives you a huge performance
gain.
> Of course, looking at hsqldb, stored procedures etc would be written in Java,
> just as the rest of the program, and executed potentially within the same
> virtual machine ... Intersting things to think about.
Done it already. Love it. But other RDBMS have support of java stored
procedures too.
Fredrik Bertilsson
http://butler.sourceforge.net
.
- Follow-Ups:
- Re: SQL
- From: Christian Brunschen
- Re: SQL
- References:
- Prev by Date: Re: SQL
- Next by Date: Re: SQL
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
