Re: EJB w/ different DB's

2000-01-17 Thread Robert Krüger
At 09:01 17.01.00 , Magnus Rydin wrote: no offense but don't you guys think this rather off-topic. this is at most a general ejb topic that should be discussed on a list like ejb-interest (if you discuss the usability of a particular database for ejb) robert >Elias Martensson wrote: > > > P

Re: EJB w/ different DB's

2000-01-17 Thread Magnus Rydin
Elias Martensson wrote: > Perhaps. But even freaky projecs grow and it can be difficult to change > once locked up. Also, why not at least get a free DB that supports > transactions even if your project is freaky? Exactly.

Re: EJB w/ different DB's

2000-01-13 Thread Magnus Rydin
> I assume you didn't read my earlier discussion as to why MySQL is more or > less always a bad idea? Yes I did. And as you said, its _more or less_ always a bad idea. There is always those freaky project with extremely temporary data, low budget, prototyping or something else that could make the

Re: EJB w/ different DB's

2000-01-11 Thread Elias Martensson
On Mon, 10 Jan 2000, Magnus Rydin wrote: > > > But if your system does not need this (now or in the future), Databasesystems > > > like MySQL is excellent. > > > > Under what cicumstances is mysql better than one of the four? Or even > > PostgreSQL? > > _like_ MySQL :) > That is small, cheap, an

Re: EJB w/ different DB's

2000-01-10 Thread Magnus Rydin
> > But if your system does not need this (now or in the future), Databasesystems > > like MySQL is excellent. > > Under what cicumstances is mysql better than one of the four? Or even > PostgreSQL? _like_ MySQL :) That is small, cheap, and fast on fairly simple types of DBs. -- WebTeknik AB Se

Re: EJB w/ different DB's

2000-01-07 Thread Elias Martensson
On Fri, 7 Jan 2000, Magnus Rydin wrote: > Foreign keys are good for making sure your data is consistant, for example you > cant reference a bank account that does not exist. > They are also good for defining delete rules, such as if this order is deleted, > make sure all orderrows are deleted too

Re: EJB w/ different DB's

2000-01-06 Thread Magnus Rydin
Foreign keys are good for making sure your data is consistant, for example you cant reference a bank account that does not exist. They are also good for defining delete rules, such as if this order is deleted, make sure all orderrows are deleted too. Correctly defined, they also speed up searching

RE: EJB w/ different DB's

2000-01-06 Thread Elias Martensson
On Wed, 5 Jan 2000, Kucera, Rich wrote: > Where's the beef in EJB anyway? I thought we had a transactional layer in > middleware with ejb... > datasources wouldn't necessarily need to be transactional themselves (they > wouldn't need to be > full-blown databases). You can't do it. In the end t

RE: EJB w/ different DB's

2000-01-06 Thread Elias Martensson
On Wed, 5 Jan 2000, Kucera, Rich wrote: > Isn't container-managed transactions the point of EJBs anyway? So database > transaction > facilities are no longer mission critical? Or am I missing something... Yes, No. Container-managed transactions are a big point of using EJB's. But what transacti

RE: EJB w/ different DB's

2000-01-05 Thread Kucera, Rich
> From: Robert Krüger [SMTP:[EMAIL PROTECTED]] > > "Kucera, Rich" wrote: > > > Isn't container-managed transactions the point of EJBs anyway? So > database > > transaction > > facilities are no longer mission critical? Or am I missing something... > > > > you are. there's no point in container

Re: EJB w/ different DB's

2000-01-05 Thread Robert Krüger
"Kucera, Rich" wrote: > Isn't container-managed transactions the point of EJBs anyway? So database > transaction > facilities are no longer mission critical? Or am I missing something... > you are. there's no point in container-managing transactions if your datasources are non-transactional. th

RE: EJB w/ different DB's

2000-01-05 Thread Jacob Smullyan
> Isn't container-managed transactions the point of > EJBs anyway? So database > transaction > facilities are no longer mission critical? Or am I > missing something... I believe that the EJB container always relies on the database to supply the transactional capability. If you use MySQL with E

RE: EJB w/ different DB's

2000-01-05 Thread Kucera, Rich
useful for visual design tools so designers can more easily generate excess complexity or something to that effect) > -Original Message- > From: Elias Martensson [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, January 04, 2000 7:13 PM > To: Orion-Interest > Cc: Orion-Interest

Re: EJB w/ different DB's

2000-01-04 Thread Elias Martensson
On Tue, 4 Jan 2000, Brien Voorhees wrote: > From: "Frank Apap" <[EMAIL PROTECTED]> > > I am currently using hSql for my db with my ejb operations, but I want to > > switch over to a more reliable and documented db. Does anyone have any > > recommendations for simply but reliable database that wi

RE: EJB w/ different DB's

2000-01-04 Thread Neville Burnell
: Wednesday, 5 January 2000 8:03 AM > To: Orion-Interest > Subject: EJB w/ different DB's > > > I am currently using hSql for my db with my ejb operations, > but I want to > switch over to a more reliable and documented db. Does > anyone have any > recommendations

Re: EJB w/ different DB's

2000-01-04 Thread Jacob Smullyan
I use and enjoy MySQL. However, in EJB work, you may need or want a dbms that supports transactions. PostgreSQL is an full-featured open-source alternative. Other databases that can be used more or less for free include DBMaker (you need to buy a license if you want more than four concurrent co

Re: EJB w/ different DB's

2000-01-04 Thread Brien Voorhees
From: "Frank Apap" <[EMAIL PROTECTED]> > I am currently using hSql for my db with my ejb operations, but I want to > switch over to a more reliable and documented db. Does anyone have any > recommendations for simply but reliable database that will be easy to switch > to? I don't know if it inte

EJB w/ different DB's

2000-01-04 Thread Frank Apap
I am currently using hSql for my db with my ejb operations, but I want to switch over to a more reliable and documented db. Does anyone have any recommendations for simply but reliable database that will be easy to switch to?