Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 34609 invoked from network); 29 Jun 2002 14:35:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 29 Jun 2002 14:35:08 -0000 Received: (qmail 1799 invoked by uid 97); 29 Jun 2002 14:34:47 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 1772 invoked by uid 97); 29 Jun 2002 14:34:46 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 1748 invoked by uid 98); 29 Jun 2002 14:34:46 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <007301c21f72$0cf5e6d0$2201a8c0@ANTO1> Reply-To: "Anthony Geoghegan" From: "Anthony Geoghegan" To: "Tomcat Users List" References: <01C21ECE.846B0E60.clayg@newobjectivity.com> <3D1D6C78.8000308@gdc.wpi.edu> Subject: Re: The best website database! Date: Sat, 29 Jun 2002 15:37:01 +0200 Organization: Xpert Safety MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N I agree fully with Liam I'm an Apache/Tomcat user with a MySQL database, I use MySQL Front and have found it to be an excellent client application for accessing, importing and exporting data. Access can export data to CSV format which can simply be imported via MySQL Front for cross compatibility. Beware though, there are certain MySQL issue to be aware of: 1/ No support for UNION (at least in 3.23) 2/ No support for Sub-Queries 3/ No stored procedures or even stored queries/views (except in a sql text file). A variety of workarounds are available some of them more successful than others though. And it's not difficult to install. Best Regards, Anthony Geoghegan. J2EE & Oracle Consultant. ----- Original Message ----- From: "Liam Morley" To: "Tomcat Users List" Sent: Saturday, June 29, 2002 10:14 AM Subject: Re: The best website database! > I've only witnessed one occasion where someone else was able to do > something pretty cool with Access, but it was sufficient enough for > Access to earn a bit of respect from me. > > I think many Tomcat users use MySQL and PostgresSQL due to the fact that > they've got an open-source (as well as free) solution. At least I do; I > can't afford Oracle, nor do I need it. > > Will, > I use MySQL, and I'm happy with the MySQL Front free gui interface for > it, however I don't think it's /quite/ what you're looking for. You > don't design queries in MySQL (or in other apps I've seen) the same > hands-off way you can in Access. Be this a blessing or a curse, I > couldn't tell you. MySQL Front's website has > some screenshots, check them out and see if they're helpful at all. > > Liam Morley > > Clay Graham wrote: > > >well I have never heard any of my friends say MSACCESS is good for anything. > > > >most small tomcat sites that I know use MySql or postgresSQL, most big ones use Oracle 8i/9i > > > >clay > > > >-----Original Message----- > >From: Will Hartung [SMTP:willh@msoft.com] > >Sent: Friday, June 28, 2002 6:10 PM > >To: Tomcat Users List > >Subject: Re: The best website database! > > > >----- Original Message ----- > >From: > > > > > >>Hi All > >> > >>I currently use MS ACCESS as my backend to my website and other developers > >> > >> > >in > > > > > >>the forum have advised this is not a good choice and I am aware of this > >> > >> > >but I > > > > > >>was forced to use it as all data comes to me in MS ACCESS from database > >> > >> > >admin > > > > > >>that supply the data for the website. I want to know what is the best > >>database to use for a website? > >> > >> > > > >"It Depends" > > > >Now that that is out of the way... > > > > > > > >>features I am looking for are: > >> > >>1- An excellent GUI (Very important) front like MS ACCESS where I can > >> > >> > >quickly > > > > > >>design queries, tables and so on. I normally design all the queries in MS > >>ACCESS and then I just write the single line command "SELECT QUERY1" > >> > >> > >rather > > > > > >>than writing the full query in a javabean or jsp page by hand as this > >> > >> > >saves > > > > > >>me alot of time. > >> > >> > > > >Ideally, you will, in time, wean yourself of this reliance, as most > >databases do not have a GUI. In the long term it's better to have a more > >intimate relathionship with SQL, minimally for performance reasons. But, it > >seems pretty clear you haven't reached that threshold yet. > > > >However, all is not completely lost. > > > >One of the Neat Things(tm) about MS ACCESS is not so much that it has a > >built-in database based on Microsofts Jet Engine, but that it can act as a > >central access point for, technically, any number of ODBC compliant > >databases. So, you can theoretically still use ACCESS as your primary > >database, but have all of the tables be linked from the true database host. > > > >This will certainly cost you performance, and the queries you devise may not > >work quite like they do in native ACCESS, but it will be close. Particularly > >if you are sticking close to the most basic of SQL functionality, and not > >relying on a lot of the higher level functions provided within ACCESS. > > > >If you're using mostly "Pure SQL", then ACCESS is simply a data broker, and > >yet another layer between your app and your DB. > > > >As long as the contention and locking facilities are being used in the > >native backend, versus within ACCESS, you should gain quite a bit of > >reliablity over pure ACCESS as well. I'm not totally sure if this is the > >case, but it probably is, again for basic SQL statements. > > > >The goal is to use ACCESS simply as an interface into your new database, and > >have it broker your SQL statements to and from the database, with hopefully > >as little intervention as possible. Your "SELECT QUERY1" will still work, > >however, but beware that ACCESS will potentially happily suck in all of the > >data from the new DB, churn on it, and then spit it back out to you. > >Depending on the query, this can be expensive and isn't what you want. If > >you like the simplicity of "SELECT QUERY1" from ACCESS, I would suggest that > >you perhaps use ACCESS to develop your basic queries, and then use the > >actual SQL generated to turn them into VIEWS on the host DB, so the SQL in > >your Java becomes "SELECT * FROM VIEW1". > > > >Again, it's almost always better to use the literal SQL rather than VIEWs, > >etc. ESPECIALLY if you're joining them together. "SELECT * FROM VIEW1, VIEW2 > >WHERE ..." CAN be very expensive. It all depends. > > > >But, when you data or activity gets big enough to actually notice the > >performance dogging, this kind of stuff tends to float to the top pretty > >quick, so when you need to fix it, you'll find it. These kinds of things > >work great with 10 rows in the tables, and die horribly with 10000 rows. > > > >You WILL have issue with BLOBs of any kind, however. > > > >Of course, if you continue to receive data from your admin in ACCESS format, > >you will need a way to convert that data into the new back end. Ideally, > >this to can be automated from ACCESS as well: INSERT INTO NewBackEndTable > >SELECT * FROM OriginalACCESSTable. > > > >So, the point being, that even if you go to a new database, you do not > >necessarily have to leave the capabilites of ACCESS behind. Eventually, > >particularly as your site gets more loaded, you will want to yank ACCESS out > >of the loop and go direct, but it wouldn't surprise me if that's farther > >away than you may think. It depends on your site. > > > >As to which backend, Oracle and SQL Server are more than capable. Oracle has > >very good direct JDBC support, whereas SQL Server does not, the JDBC drivers > >come from third parties. However you're probably using the JDBC<->ODBC > >bridge. I've never used it in anger, so can't say anything to its > >productiion worthiness, however I've never heard glowing things about it. > > > >But if you continue to talk to ACCESS, you're pretty much stuck with it > >anyhow. > > > >Both of these DBs are quite expensive. > > > >mysql's biggest point against it is that it does not conform as well to the > >standard SQL syntax and behaviors. It has other issues with it, but many > >folks are satisfied and work around them. I don't know how well its ODBC > >drivers may work. > > > >PostgreSQL has more conventional SQL DB capabilities, and its own hoards of > >raving fans, and decent Java support, so it should be considered as well. I > >don't know how good its ODBC driver is either, however. > > > >These two DB's are, of course, free. > > > >Has anyone used the new "desktop" MS SQL database engine? Isn't that the > >backend of the Latest/Greatest ACCESS? > > > >You may also want to consider something like SQL Anywhere from Sybase, or > >even Interbase/Firebird from WhateverBorlandIsCalledToday. They're cheap, > >and not slouches for basic DB stuff. Sure, you can't have clusters of them > >running on Mega SMP machines. But I really doubt that's the issue today. > > > >When the modern "desktop" is a 1.5GHz machine, with 512MB of RAM, there's a > >LOT of capability in a "workgroup" database server today. > > > >Let's all raise our hands if you've supported over a hundred users on a > >33Mhz 68030 with 64MB of RAM? App and DB...Come on..up with the > >hands....Anyone? > > > >Anyway, hope that helps. > > > >As said in the beginning, it depends. > > > >Best Regards, > > > >Will Hartung > >(willh@msoft.com) > > > > > > > > > > > >-- > >To unsubscribe, e-mail: > >For additional commands, e-mail: > > > > > >-- > >To unsubscribe, e-mail: > >For additional commands, e-mail: > > > > > > > > > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: