Re: [OT] SQL woes
What are the advantages of PostgreSQl over mySQL I currently use mySQL everywhere and it works well - at least for what I need it for!! Andy On Thu, 2003-08-21 at 16:12, Toby Corkindale wrote: On Sun, Aug 17, 2003 at 06:03:13PM +0100, Paul Makepeace wrote: On Sun, Aug 17, 2003 at 09:51:13AM -0700, Randal L. Schwartz wrote: (And people who use MySQL wonder what the value of subselects are! :) Subselects are in MySQL 4.1 (currently alpha). http://www.mysql.com/press/release_2003_05.html Ick. Have they got around to supporting transactions yet? :P I'd still say toss it and use PostgreSQL. Ditto. Don't understand the hype around MySQL, personally. tjc
Installing Perl on End Of Lifed Irix 5.3
Hi, Anyone have experience of installing Perl on Irix 5.3? I'm sure there are lots of good reasons for not even beginning to attempt this but putting that to one side... The latest I have on the machine, an Indigo, is 5.004 from http://reality.sgiweb.org/scotth/info/perl5.html I have MySQL 3.20.32a running happily enough on the machine and just want to do some simple DBI stuff with it. Latest DBI needs a later version of Perl, quite understandably so my question is: A. Do I take a later version of Perl and build that? If so, which one and what issues am I going to hit on the way? B. Do I take older versions of the packages I need to go with my old hardware, old OS and old database? C. None of the above. Any thoughts or ideas on this would be great. Many Thanks Chris PS. Apologies administrator for sending this with the wrong email address, please disregard that copy, Thanks.
Re: Mr. Brocard database tools in focus
On Thu, 21 Aug 2003, Luis Campos de Carvalho wrote:
I wonder about what you use to store large amounts of data.
Could you please teach me about your
data-{storage,classification,retrieval,maintenance} tools?
James and Pierre have given talks on the Pixie and Vx tools which Fotango
use to store data:
http://opensource.fotango.com/
http://search.cpan.org/author/JDUNCAN/Pixie/lib/Pixie.pm
http://www.perladvent.org/2002/24th/
HTH.
Mark.
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
Re: [OT] SQL woes
Toby Corkindale [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2003 at 06:03:13PM +0100, Paul Makepeace wrote: On Sun, Aug 17, 2003 at 09:51:13AM -0700, Randal L. Schwartz wrote: (And people who use MySQL wonder what the value of subselects are! :) Subselects are in MySQL 4.1 (currently alpha). http://www.mysql.com/press/release_2003_05.html Ick. Have they got around to supporting transactions yet? :P Transactions have been supported for a while, apparently. Dunno as I don't use MySQL myself, but it's a frequent rebuff. I think you have to select the berkelydb backend table storage module. Anyway, If you want a high end database with the MySQL label, it looks like they've just gone a rebranding rampage with SAPDB and it's emerged as MySQL Max... http://www.mysql.com/press/release_2003_24.html http://www.mysql.com/maxdb/ That probably has more features that one would expect. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 09:54:22AM +0100, Andy Ford wrote: What are the advantages of PostgreSQl over mySQL The first few advantages that come to mind: It scales. :D It supports (several varieties of) transactions. It can write internally consistent backup dumps. It supports write-ahead-logging. (Basically the same deal as journalled filesystems, only in-database; and no, just because you're using ext3fs or reiserfs, doesn't mean you achieve the same thing) It supports stored procedures (in tcl, perl, and plpgsql). It has also supported all the above for quite a while now and has a good track record. MySQL supporters tend to point out things like oh, but mysql supports that now - in the latest alpha CVS snapshot. I currently use mySQL everywhere and it works well - at least for what I need it for!! MySQL is good for some stuff - it used to be a fairly lightweight SQL interface to a some basic backend storage. If you just want to go around inserting and selecting data for your home accounting or your webpage, it's fine. Doesn't use too much memory or CPU, works fine. It's just when you want to deal with large/commercial projects that it tends to fall down. But I tend to use it for everything, as well; on modern hardware the slightly larger footprint of Pg isn't a problem. tjc.
Re: Mr. Brocard database tools in focus
I like the idea of this: http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ These guys are a little evangelical but I find the idea intriguing. I'm still not too sure how easy it would be to remember to have the data migrate itself when you change your classes. I think you'd need some fairly rigorous run-time consistency checks. Has anything like this been done in perl? There is a ruby implementation of this, so it can't be that hard :).
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 09:54:22AM +0100, Andy Ford wrote: What are the advantages of PostgreSQl over mySQL The first few advantages that come to mind: It scales. :D It supports (several varieties of) transactions. It can write internally consistent backup dumps. It supports write-ahead-logging. (Basically the same deal as journalled filesystems, only in-database; and no, just because you're using ext3fs or reiserfs, doesn't mean you achieve the same thing) It supports stored procedures (in tcl, perl, and plpgsql). On the MySQL plus side I've found HASH Tables to be invaluable for recording lots of transactions without the disk (i.e., in RAM buckets). And one day when I can afford a cluster I'm hoping to implement the MySQL DB replication Hack (outlined in Linux Server Hacks) to distribute parts of the database onto the nodes. On the negative side, MySQL's lack of subqueries has been a real bummer. NIge -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: [OT] SQL woes
On Fri, 22 Aug 2003, Nigel Hamilton wrote: And one day when I can afford a cluster I'm hoping to implement the MySQL DB replication Hack (outlined in Linux Server Hacks) to distribute parts of the database onto the nodes. I'm using that and it works beautifully. It'd also very easy to recover when you do something stupid resulting in the database getting out of sync (on a test box - I try to keep away from production systems when I am on the stupid). Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ ADSL Broadband available now
Re: Prevayler
Steve Keay sent the following bits through the ether: Has anything like this been done in perl? There is a ruby implementation of this, so it can't be that hard :). http://search.cpan.org/dist/Class-Prevayler/ It's a nice idea with a little too much hype, but I generally don't have databases which fit in memory. I mean, otherwise they'd be in hashes anyway ;-) Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... The statement is now easier to understand. It is also wrong
Re: Prevayler
Leon Brocard wrote: http://search.cpan.org/dist/Class-Prevayler/ It's a nice idea with a little too much hype, but I generally don't have databases which fit in memory. I mean, otherwise they'd be in hashes anyway ;-) It's a curious idea shrouded by great mountain ranges of bombast. My main worry is this: Do you mean I can simply have my objects in RAM and forget all that database hassle? That's right. As far as I can see, there are two issues being conflated here, maybe three: a) whether data lives on the disk or in RAM, b) architecturally, whether a system is based on RDBMS stuff like queries and tables, or not. Not would include other storage methodologies - like file systems, graphs, LDAP databases, object persistance-based stuff, ... c) whether stuff can be sped up by concentrating on writing CHANGES to disk in the order of change (ie. keeping a log). (c) is done by journalling filesystems and many RDBMSs anyway. (a) happens increasingly the more you can have large caches, or such things as heap tables in MySQL or persistent RAM that looks like a disk. (b) is the key thing. Since the spirit of Codd moved upon the face of the waters, people have been saying arg, SQL will be/is way too slow, and database supporters have said things like but queries get optimised - and you can query in any direction - and it'll be easier to support. RAM is getting cheaper. Keeping stuff in RAM becomes obviously a good idea. JFSs are also becoming increasingly popular. These are all unambiguously Good Things. The principal advantages of RDBMSs, IMHO, are: 1. Clarity. You need to declare what your data looks like, and the system will then verify that it does[1]. This also makes it easier for someone else to come along and query it ... (See also design by contract and XML schemae). 2. Scaleability. Unless you do something silly, you're dealing with the same kind of data as the database has already been tuned against, and it shouldn't scale too badly. 3. Atomicity (again, because you know what your data is like). 4. Concurrency is, pretty much[2] looked after. Concurrency-safe code is a slight pig to write and an utter pig to test. Using RDBMSs removes or makes much less likely many of the failure modes. Really scary quote: you are no longer limited to writing feeble client code. You now have the means to actually write server code. It is the way object orientation was intended all along; but it is certainly not for wimps OO was intended to make software development faster and safer. OO is, in fact, for wimps. In fact, all modern computing languages are for wimps. For sake of balance[3], I should point out what I see as the key disadvantages of RDBMSs: 1. Change control. You change your schema, and need to get that change out to however many people are using your application anywhere in the world. No sneakily detecting old files and reading them in a backwards-compatibility mode, you've gotta big-bang your structure over to the new way. And RDBMSs don't like doing that, you can't just say here is the new schema, convert, you need to muck around with lots of ALTER TABLE stuff.[666] 2. SQL syntax is a bastard. Everything is different; look how many ways there are to specify records according to whether you're updating or inserting. Oh and DBMSs all work slightly/very differently. 3. You need an RDBMS. 4. Most RDBMSs, AFAIK, are not that helpful with good design[4]. Inheritance of record types is often not supported (VAN is a kind of vehicle) (Oracle probably does much here; I've not used it for ages). If (as you should do) you code your data validation into your database schema, you may then need to code it again - eg. I've just filled in a form of data with some garbage. Does the system throw that at the DB, catch the error, and give me the error? Or can it pre-check? This point is hopefully wrong if you know enough and use an adequately expensive database. 5. RDBMSs, for some applications, will slow you down awfully. 6. And you've got to shunt data in and out of SQL. This *can* be centralised/automated etc, but can also be a pain in the neck. Lots of overhead all round. YMMV. Has anything like this been done in perl? There is a ruby implementation of this, so it can't be that hard :). The difficult bit will be writing one that is really helpful to people doing large, difficult projects. The difficult part of *that* is knowing when you've done it. -- ti' [1] well, sometimes. Not so much if you're using MySQL. [2] except, who actually uses REPEATABLE READ mode in production? [3] y'know, the idea that you should say helpful, true things, rather than bombastically ranting on about how much your favourite solution rocks [4] following such rules as make things testable, don't repeat yourself, use inheritance so similar entities can be treated similarly [666] if you've only got one live database, no beta database and no other users of your system, this problem
Re: Mr. Brocard database tools in focus
On Fri, 22 Aug 2003 11:52, Steve Keay wrote; SK http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ SK These guys are a little evangelical but I find the idea SK intriguing. I'm still not too sure how easy it would be to SK remember to have the data migrate itself when you change your SK classes. I think you'd need some fairly rigorous run-time SK consistency checks. Both Pixie and Tangram are based on this principle; Tangram calls it `orthogonal' storage of data; in essence, it's not interfering with the damned objects just for your persistence mechanism. For most applications, Pixie will be faster and more convenient, but for some types of data access (eg, OLTP) it really reduces the number of times that you have to hit the disk if you know your record size up front - in which case a system like Tangram where you have to explicitly tell the tool what columns you've got, and how big they are is better. -- Sam Vilain, [EMAIL PROTECTED] The flush toilet is the basis of Western civilization. ALAN COULT
Re: [OT] SQL woes
On Thu, 21 Aug 2003 16:12, Toby Corkindale wrote; TC Ick. Have they got around to supporting transactions yet? :P No, they're too dumb for that - but a company called InnoDB basically re-wrote the core parts of MySQL and called it a storage back-end. It's free and included in the MySQL distribution, except the hot backup license (very smart move). In fact, it's even compiled in by default with Debian stable, all you need to do is change some config options, bounce MySQL, re-create all your tables reload your data :-) and you're away laughing ... works very well using raw LVM partitions as tablespaces (I haven't yet found a way to add more table space online, but I may just be overlooking the obvious). http://www.innodb.com/features.html -- Sam Vilain, [EMAIL PROTECTED] UNIX, n: Anything which is subtly incompatible with everything else claming to be a UNIX.
Re: Prevayler
Steve Keay sent the following bits through the ether: Has anything like this been done in perl? There is a ruby implementation of this, so it can't be that hard :). http://search.cpan.org/dist/Class-Prevayler/ It's a nice idea with a little too much hype, but I generally don't have databases which fit in memory. I mean, otherwise they'd be in hashes anyway ;-) Yes ... just imagine a world where we had terrabytes of RAM - everything would be stored in vast object pools. In the meantime, the 'tyranny of disk seek time' is still with us. Which means a 3NF+ relational model is still needed to optimise disk storage - and if you're dealing with lots of relational data, an RDBMS is still the best way to manipulate it (locking, index/query optimisation etc). A half-way position is MySQL's RAM (i.e., hash) tables which can cache 'live' transaction objects before they are drawn down to disk. NIge -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: [OT] SQL woes
Andy Ford wrote: What are the advantages of PostgreSQl over mySQL I currently use mySQL everywhere and it works well - at least for what I need it for!! Hello Andy, and Perl M[ou]ngers. IMHO, MySQL is the fastest database engine on the Open-Source and Commercial markets. On the other hand, PostgreSQL have some interesting features, like support for a built-in scripting language and transactions. This makes PostgreSQL a quite interesting tool for Open-Source solutions development. AFAIK, PostgreSQL uses a PL/SQL-like scripting language, and this is quite interesting for portability questions: somebody could easily migrate his/her database from/to oracle faster. I use to see this as a good thing. The main advantage of using MySQL is speed -- web based applications suffers a lot from badly optimized database access. The bad thing about this is that speed comes from dropping important features that could be useful for other uses, like billing: nobody sane will use a MySQL to control billing transactions: it's too complex to protect data from failures and handle errors in a comprehensible way. That's it. Just my two pence. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Luis Campos de Carvalho is Computer Scientist, PerlMonk [SiteDocClan], Cascavel-pm Moderator, Unix Sys Admin Certified Oracle DBA http://br.geocities.com/monsieur_champs/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Prevayler
On Fri, 22 Aug 2003 13:13, Nigel Hamilton wrote; NH Yes ... just imagine a world where we had terrabytes of RAM - NH everything would be stored in vast object pools. FWIW, the NZ Stock Exchance runs on a replicated RAM database (on Linux). -- Sam Vilain, [EMAIL PROTECTED] Among economists, the real world is generally considered to be a special case. - anon.
Re: Installing Perl on End Of Lifed Irix 5.3
On Fri, 22 Aug 2003 10:28, Chris Young wrote; CY B. Do I take older versions of the packages I need to go with my CY old hardware, old OS and old database? Try DBI 1.14 or a near later version. That was the earliest known stable version AFAIK. -- Sam Vilain, [EMAIL PROTECTED] An OO surgeon would hand the scalpel to the patient and say: now perform this operation on yourself!.
Re: Prevayler
On Fri, Aug 22, 2003 at 01:40:21PM +0100, Sam Vilain wrote: FWIW, the NZ Stock Exchance runs on a replicated RAM database (on Linux). Is that the NZ stock exchange that crashed recently because of a software bug (see latest RISKS)? -- David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david For every vengeance, there is an equal and opposite revengeance. -- Cartoon Law X
Re: [OT] SQL woes
From: Andy Ford [EMAIL PROTECTED] Date: 8/22/03 8:54:22 AM What are the advantages of PostgreSQl over mySQL I currently use mySQL everywhere and it works well - at least for what I need it for!! MySQL is just a file-based storage system with a pseudo-SQL interface. It doesn't support many of the things that you'd expect in a real SQL implementation, for example: * Transactions * Subselects * Referential integrity PostgreSQL has (I believe[1]) all of these things. hth, Dave... [1] I don't use it. I still use MySQL in most places :( -- http://www.dave.org.uk Let me see you make decisions, without your television - Depeche Mode (Stripped)
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 06:20:39AM -0700, Dave Cross wrote: MySQL is just a file-based storage system with a pseudo-SQL interface. It doesn't support many of the things that you'd expect in a real SQL implementation, for example: * Transactions * Referential integrity Innodb tables give you these in modern mysqls. * Subselects Not yet, scheduled for 4.1 though. Besides, people really don't expect those things. It's just the people who've used other RDBMSs before and enjoyed the bondage and discipline that expect them. Not that I'm against hating software, but I do have this preference for informed hate. -- Richard Clamp [EMAIL PROTECTED]
Re: [OT] SQL woes
Luis == Luis Campos de Carvalho [EMAIL PROTECTED] writes: LuisIMHO, MySQL is the fastest database engine on the Open-Source and Luis Commercial markets. Only for a loose definition of database. Certainly not one with transactions. When you move all your tables to InnoDB, the results actually favor PostgreSQL for what I've seen so far. LuisOn the other hand, PostgreSQL have some interesting features, like Luis support for a built-in scripting language and transactions. This makes Luis PostgreSQL a quite interesting tool for Open-Source solutions Luis development. And don't forget subselects, views, triggers, foreign keys, and all the other goodies from proper SQL 92 compliance. MySQL is a fine junior SQL engine. But it really doesn't provide a way to enforce business rules in the engine - that was not its initial goal. And when data integrity is important, you want to ensure good foreign keys and triggers that will keep your data from getting out of whack because of application programmer error, and MySQL says no, that stuff all belongs in the application, not the database. Fine decision to keep it simple, but in the real world, that's a dangerous decision. LuisAFAIK, PostgreSQL uses a PL/SQL-like scripting language, and this Luis is quite interesting for portability questions: somebody could easily Luis migrate his/her database from/to oracle faster. I use to see this as a Luis good thing. LuisThe main advantage of using MySQL is speed I think that's actually a myth now. Maybe in the past it was a clear winner, but more often than not, a well-tuned PostgreSQL install will beat a well-tuned MySQL install on the same hardware under some serious stress. Luis-- web based Luis applications suffers a lot from badly optimized database access. The Luis bad thing about this is that speed comes from dropping important Luis features that could be useful for other uses, like billing: nobody Luis sane will use a MySQL to control billing transactions: it's too Luis complex to protect data from failures and handle errors in a Luis comprehensible way. MySQL is *just* now getting transactions. PostgreSQL has had some very good experts working on transactions for years now, and they're much further along on the trial-and-error curve that MySQL is just now starting. In conclusion, if you want a speedy ACID-compliant enforced-business-rules database with full SQL support (not a subset), PostgreSQL wins, and MySQL is still two or three years away. On the other hand, if you wanna be able to ask a question on a general mailing list, the MySQL community is probably ten times the size of the PostgreSQL community, and more applications have been written that presume MySQL's quirky SQL subset. That'd be the *only* reason in my mind to go with MySQL over Pg at this point. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: [OT] SQL woes
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Cross Sent: 22 August 2003 14:21 To: [EMAIL PROTECTED] Subject: Re: [OT] SQL woes MySQL is just a file-based storage system with a pseudo-SQL interface. It doesn't support many of the things that you'd expect in a real SQL implementation, for example: * Transactions * Subselects * Referential integrity Not sure about the referential integrity but it does have transactions and subselects are coming in 4.1. (Currently 4.0.14) MySQL Server (version 3.23-max and all versions 4.0 and above) supports transactions with the InnoDB and BDB Transactional storage engines. InnoDB provides full ACID compliance [0] Andy [0] http://www.mysql.com/doc/en/ANSI_diff_Transactions.html
Re: [OT] SQL woes
Randal == Randal L Schwartz [EMAIL PROTECTED] writes: Randal MySQL is a fine junior SQL engine. But it really doesn't provide a Randal way to enforce business rules in the engine - that was not its initial Randal goal. And when data integrity is important, you want to ensure good Randal foreign keys and triggers that will keep your data from getting out of Randal whack because of application programmer error, and MySQL says no, Randal that stuff all belongs in the application, not the database. Fine Randal decision to keep it simple, but in the real world, that's a dangerous Randal decision. Let me explain this a bit better. Suppose you have a deployed app with many components. And now some accounting audit dude comes along and says OK, we need a trail of every time a billing record is added or changed. With MySQL, you have to go into every app in whatever language it has been written, and add the extra audit code. In PostgreSQL, it's trivial to add an after commit trigger to flash the old and new records into a seperate record for auditing, and that works with whatever way you are connecting to the database, because it's *in* the database. Heck, with PL/Perl, you can even page someone when a certain record is set. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 06:45:21AM -0700, Randal L. Schwartz wrote: In conclusion, if you want a speedy ACID-compliant enforced-business-rules database with full SQL support (not a subset), PostgreSQL wins, and MySQL is still two or three years away. On the other hand, if you wanna be able to ask a question on a general mailing list, the MySQL community is probably ten times the size of the PostgreSQL community, and more applications have been written that presume MySQL's quirky SQL subset. That'd be the *only* reason in my mind to go with MySQL over Pg at this point. On the third hand, if you want _real_ speed, _and_ transactions, but none of the other neat stuff; and if your system doesn't have much in the way of concurrent writes; SQLite is a whole lot easier to set up and admin than MySQL. (I'm using it for most of my light-weight web apps these days.) Roger
Re: [OT] SQL woes
Richard == Richard Clamp [EMAIL PROTECTED] writes: Richard On Fri, Aug 22, 2003 at 06:20:39AM -0700, Dave Cross wrote: MySQL is just a file-based storage system with a pseudo-SQL interface. It doesn't support many of the things that you'd expect in a real SQL implementation, for example: * Transactions * Referential integrity Richard Innodb tables give you these in modern mysqls. At a speed cost that makes it slower than Pg, and an earlier spot on the design curve which Pg has already matured on. * Subselects Richard Not yet, scheduled for 4.1 though. Richard Besides, people really don't expect those things. It's just the Richard people who've used other RDBMSs before and enjoyed the bondage and Richard discipline that expect them. People coming from flat files and DBM don't expect them. Now that I've seen subselects and triggers and views and stored procedures in action, I don't think I can deploy anything with a dozen tables or more without them. MySQL - fine for people who want a light subset-SQL interface to structured data PostgreSQL - Oracle without the price -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 02:59:14PM +0100, Roger Burton West said: On the third hand, if you want _real_ speed, _and_ transactions, but none of the other neat stuff; and if your system doesn't have much in the way of concurrent writes; SQLite is a whole lot easier to set up and admin than MySQL. (I'm using it for most of my light-weight web apps these days.) But suffers, IIRC, from concurrency problems. So, to sum up this thread : 1. PostGres has some advantages 2. MySql has some advantages 3. Oracle has some advantages 4. SQLite has some advantages 5. All of the above have disadvantages. 6. There will be a film. At 11.
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 03:07:19PM +0100, Simon Wistow wrote: [SQLite] But suffers, IIRC, from concurrency problems. On writing, yes. Hence doesn't have much in the way of concurrent writes. R
Re: [OT] SQL woes
Randal L. Schwartz [EMAIL PROTECTED] wrote: MySQL is *just* now getting transactions. PostgreSQL has had some very good experts working on transactions for years now, and they're much further along on the trial-and-error curve that MySQL is just now starting. I'd just like to point out that postgresql doesn't have nested transactions. This annoyed me because I had to think about my design harder. :-) -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: [OT] SQL woes
On Friday, August 22, 2003, at 11:28 am, Dominic Mitchell wrote: Toby Corkindale [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2003 at 06:03:13PM +0100, Paul Makepeace wrote: On Sun, Aug 17, 2003 at 09:51:13AM -0700, Randal L. Schwartz wrote: (And people who use MySQL wonder what the value of subselects are! :) Subselects are in MySQL 4.1 (currently alpha). http://www.mysql.com/press/release_2003_05.html Ick. Have they got around to supporting transactions yet? :P Transactions have been supported for a while, apparently. Dunno as I don't use MySQL myself, but it's a frequent rebuff. I think you have to select the berkelydb backend table storage module. Yeah. You do get transactions if you use innodb tables, and have had for several years. The sub-select support is very beta at the moment and, annoyingly, doesn't work with innodb tables so you can't have transactions and sub-selects at the same time! MySQL can be a lot better than the worse-case description given by many but, given the choice, PostgreSQL would be my pick every time. A much more mature product. Adrian
Re: [OT] SQL woes
Well thanks for summing that up - it was an interesting read!! Currently I use mySQL only and don't really need transactional stuff. Now triggers I can see a need for!! I may take a look at Pg Thanks Andy On Fri, 2003-08-22 at 15:08, Randal L. Schwartz wrote: Richard == Richard Clamp [EMAIL PROTECTED] writes: Richard On Fri, Aug 22, 2003 at 06:20:39AM -0700, Dave Cross wrote: MySQL is just a file-based storage system with a pseudo-SQL interface. It doesn't support many of the things that you'd expect in a real SQL implementation, for example: * Transactions * Referential integrity Richard Innodb tables give you these in modern mysqls. At a speed cost that makes it slower than Pg, and an earlier spot on the design curve which Pg has already matured on. * Subselects Richard Not yet, scheduled for 4.1 though. Richard Besides, people really don't expect those things. It's just the Richard people who've used other RDBMSs before and enjoyed the bondage and Richard discipline that expect them. People coming from flat files and DBM don't expect them. Now that I've seen subselects and triggers and views and stored procedures in action, I don't think I can deploy anything with a dozen tables or more without them. MySQL - fine for people who want a light subset-SQL interface to structured data PostgreSQL - Oracle without the price
Re: Prevayler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Chris Devers cdevers at pobox.com [2003-08-22 11:38]: (Can ZODB [Zope Object DataBase] even work outside of Zope?) Absolultely. For example, take a look at Chandler, at www.osafoundation.org, an open source PIM that uses the ZODB as a backend. (darren) - -- Help! I'm a rock! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: This message is digitally signed and can be verified for authenticity. iD8DBQE/RjwfzsinjrVhZaoRAngQAJsF52ibSGCR3EtsHigupTcYT4YjQgCfQmGC GHgfdQPpPp5qNdyEx4l+ksY= =KrW8 -END PGP SIGNATURE-
Re: [OT] SQL woes
On Fri, 22 Aug 2003, Simon Wistow wrote: So, to sum up this thread : 1. PostGres has some advantages 2. MySql has some advantages 3. Oracle has some advantages 4. SQLite has some advantages 5. All of the above have disadvantages. 6. There will be a film. At 11. Which will be delayed for a new advertising campaign promoting MS-SQL. Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ ADSL Broadband available now
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 05:13:31PM +0100, Jason Clifford wrote: On Fri, 22 Aug 2003, Simon Wistow wrote: So, to sum up this thread : 1. PostGres has some advantages 2. MySql has some advantages 3. Oracle has some advantages 4. SQLite has some advantages 5. All of the above have disadvantages. 6. There will be a film. At 11. Which will be delayed for a new advertising campaign promoting MS-SQL. The only database written exclusively for MS Windows - so you know it must be good! (Although Sybase wasn't, was it?) tjc.
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 02:59:14PM +0100, Roger Burton West wrote: On Fri, Aug 22, 2003 at 06:45:21AM -0700, Randal L. Schwartz wrote: In conclusion, if you want a speedy ACID-compliant enforced-business-rules database with full SQL support (not a subset), PostgreSQL wins, and MySQL is still two or three years away. On the other hand, if you wanna be able to ask a question on a general mailing list, the MySQL community is probably ten times the size of the PostgreSQL community, and more applications have been written that presume MySQL's quirky SQL subset. That'd be the *only* reason in my mind to go with MySQL over Pg at this point. On the third hand, if you want _real_ speed, _and_ transactions, but none of the other neat stuff; and if your system doesn't have much in the way of concurrent writes; SQLite is a whole lot easier to set up and admin than MySQL. (I'm using it for most of my light-weight web apps these days.) Transactions, sort-of, in that you get them within a single query; but there's poor support for simultaneous-request stuff. I looked at SQLLIte a while back, and the thing that scared me off was the complete lack of locking; it required you to do that at application level. OK, you say, so it's not too hard to implement one giant all-encompassing lock at application level with a CPAN module; but then you get right back the problems that were plagueing MySQL earlier on! (coarse grained locking). history repeats itself.. tjc. -- Turning and turning in the widening gyre The falcon cannot hear the falconer; Things fall apart, the centre cannot hold; Mere anarchy is loosed upon the world.
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 06:45:21AM -0700, Randal L. Schwartz wrote: MySQL is *just* now getting transactions. PostgreSQL has had some very good experts working on transactions for years now, and they're much further along on the trial-and-error curve that MySQL is just now starting. For values of *just* approaching 3 years... If you count the MySQL+SAP combo (not forgetting that SAP had an Oracle-compatability mode...) then that number gets a whole lot bigger. Tony
Re: [OT] SQL woes
On Fri, Aug 22, 2003 at 03:30:48PM +0100, Andy Ford wrote: Well thanks for summing that up - it was an interesting read!! Currently I use mySQL only and don't really need transactional stuff. Now triggers I can see a need for!! Triggers at the db level will bite you hard at some point. If you're going to have multiple people building your application make sure you have VERY strict rules on adding triggers. Unchecked they lead to an unmaintainable mess quicker than most other things can ... Tony
RE: [OT] SQL woes
Hi, As a Perl beginner who has realised I need to set up a database, I have to add that I immediately went for MySQL due to all the attention it seems to have, and bought a few books to get me started. The whole thing - using installing etc etc looks hellish complicated AND I haven't even been able to install it. All I can see is where the files are installed in my copy of Linux. So it looks as if you already have to know what you're doing in order to use it which is useless for a beginner and teh antithesis it seems to me of what Perl is all about - because you don't already have to know what you're doing to get started/ use it. So this SQLite seems like a great idea IF it makes setting up and administering a dbase simple. Unfortunately I just looked up where I can download it, but didn't see any example code showing it working with Perl, or any documentation about how to use it with Perl. Please can you inform what do I have to do/install in order to start creating, updating and querying the database from Perl? Thanks Colin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roger Burton West Sent: 22 August 2003 14:59 To: [EMAIL PROTECTED] Subject: Re: [OT] SQL woes On Fri, Aug 22, 2003 at 06:45:21AM -0700, Randal L. Schwartz wrote: In conclusion, if you want a speedy ACID-compliant enforced-business-rules database with full SQL support (not a subset), PostgreSQL wins, and MySQL is still two or three years away. On the other hand, if you wanna be able to ask a question on a general mailing list, the MySQL community is probably ten times the size of the PostgreSQL community, and more applications have been written that presume MySQL's quirky SQL subset. That'd be the *only* reason in my mind to go with MySQL over Pg at this point. On the third hand, if you want _real_ speed, _and_ transactions, but none of the other neat stuff; and if your system doesn't have much in the way of concurrent writes; SQLite is a whole lot easier to set up and admin than MySQL. (I'm using it for most of my light-weight web apps these days.) Roger
Re: [OT] SQL woes
Dominic Mitchell [EMAIL PROTECTED] writes: Randal L. Schwartz [EMAIL PROTECTED] wrote: MySQL is *just* now getting transactions. PostgreSQL has had some very good experts working on transactions for years now, and they're much further along on the trial-and-error curve that MySQL is just now starting. I'd just like to point out that postgresql doesn't have nested transactions. This annoyed me because I had to think about my design harder. :-) It is rather annoying isn't it?
Re: [OT] SQL woes
What about Firebird? http://firebird.sourceforge.net/ does anyone here have personal experience? On paper (well, online) it compares favorably to PostgreSQL, and it can be easily embedded. richard __ Bibliocraft Ltd / www.bibliocraft.com
