Re: oracle : The lowdown
On Fri, 21 Jan 2000, G.W. Haywood wrote: > Why do so many people seem > to insist on using a sledgehammer to crack a nut? Horses for courses, > as we join our metaphors around here. Ad-Hoc queries? :-) With specs that change like water flows I'd have a very hard time giving up the relational aspect of a DB. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: oracle : The lowdown
On Thu, Jan 20, 2000 at 10:15:33PM -0800, Perrin Harkins wrote: > "G.W. Haywood" wrote: > > On Thu, 20 Jan 2000, Perrin Harkins wrote: > > > you can't guarantee your data will be in a consistent state without > > > transactions or some other way to do atomic updates > > [snip] > > > (e.g. you're running a message board and who cares if a post gets > > > lost somewhere) then transactions might be considered unnecessary > > > > Might be? Having worked with a BTREE/ISAM package written in C and > > assembler for the last 15 years or so, I wouldn't dream of using a DB > > for some of this stuff. It would just get in the way and be 100 times > > slower than my C code. I lock records as necessary so the data will > > *always* be consistent and a whole bunch of gotchas simply evaporates. > > Right, you've just implemented simple transactions. Your locking > serializes access to the data and solves race condition problems. > - Perrin Serialized access does not give you transactions with A.C.I.D. semantics. But this isn't the place to discuss that. Tim.
Re: oracle : The lowdown
"G.W. Haywood" wrote: > On Thu, 20 Jan 2000, Perrin Harkins wrote: > > you can't guarantee your data will be in a consistent state without > > transactions or some other way to do atomic updates > [snip] > > (e.g. you're running a message board and who cares if a post gets > > lost somewhere) then transactions might be considered unnecessary > > Might be? Having worked with a BTREE/ISAM package written in C and > assembler for the last 15 years or so, I wouldn't dream of using a DB > for some of this stuff. It would just get in the way and be 100 times > slower than my C code. I lock records as necessary so the data will > *always* be consistent and a whole bunch of gotchas simply evaporates. Right, you've just implemented simple transactions. Your locking serializes access to the data and solves race condition problems. - Perrin
Re: oracle : The lowdown
Hi there, On Thu, 20 Jan 2000, Perrin Harkins wrote: > We're veering WAY off-topic here Maybe. But I for one am happy for the diversion. A lot of mod-perl sites are doing just this kind of thing - after all, mod-perl is just a link in a chain, it's of no use intrinsically without some things to link together! Greg has given me some valuable insights. > you can't guarantee your data will be in a consistent state without > transactions or some other way to do atomic updates [snip] > (e.g. you're running a message board and who cares if a post gets > lost somewhere) then transactions might be considered unnecessary Might be? Having worked with a BTREE/ISAM package written in C and assembler for the last 15 years or so, I wouldn't dream of using a DB for some of this stuff. It would just get in the way and be 100 times slower than my C code. I lock records as necessary so the data will *always* be consistent and a whole bunch of gotchas simply evaporates. For a lot of things on the Web, you can even get away with just the operating system and flat files half the time. I've got to admit that the way machine performance is going there may come a time when it's just not worth the extra effort of tinkering in the guts but we aren't nearly there yet. Why do so many people seem to insist on using a sledgehammer to crack a nut? Horses for courses, as we join our metaphors around here. Just my 0.02p... 73, Ged.
Re: oracle : The lowdown
For those of you tired of this thread please excuse me, but here is MySQL's current position statement on and discussion about transactions: Disclaimer: I just helped Monty write this partly in response to some of the fruitful, to me, discussion on this list. I know this is not crucial to mod_perl but I find the "wise men who are enquirers into many things" to be one of the great things about this list, to paraphrase old Heraclitus. I learn quite a bit about quite many things by following leads and hints here as well as by seeing others problems. I'd love to see your criticism of the below either here or off the list. Ed - The question is often asked, by the curious and the critical, "Why is MySQl not a transactional database?" or "Why does MySQl not support transactions." MySQL has made a conscious decision to support another paradigm for data integrity, "atomic operations." It is our thinking and experience that atomic operations offer equal or even better integrity with much better performance. We, nonetheless, appreciate and understand the transactional database paradigm and plan, in the next few releases, on introducing transaction safe tables on a per table basis. We will be giving our users the possibility to decide if they need the speed of atomic operations or if they need to use transactional features in their applications. How does one use the features of MySQl to maintain rigorous integrity and how do these features compare with the transactional paradigm? First, in the transactional paradigm, if your applications are written in a way that is dependent on the calling of "rollback" instead of "commit" in critical situations, then transactions are more convenient. Moreover, transactions ensure that unfinished updates or corrupting activities are not commited to the database; the server is given the opportunity to do an automatic rollback and your database is saved. MySQL, in almost all cases, allows you to solve for potential problems by including simple checks before updates and by running simple scripts that check the databases for inconsistencies and automatically repair or warn if such occurs. Note that just by using the MySQL log or even adding one extra log, one can normally fix tables perfectly with no data integrity loss. Moreover, "fatal" transactional updates can be rewritten to be atomic. In fact,we will go so far as to say that all integrity problems that transactions solve can be done with LOCK TABLES or atomic updates, ensuring that you never will get an automatic abort from the database, which is a common problem with transactional databases. Not even transactions can prevent all loss if the server goes down. In such cases even a transactional system can lose data. The difference between different systems lies in just how small the time-lap is where they could lose data. No system is 100 % secure, only "secure enough". Even Oracle, reputed to be the safest of transactional databases, is reported to sometimes lose data in such situations. To be safe with MySQL you only need to have backups and have the update logging turned on. With this you can recover from any situation that you could with any transactional database. It is, of course, always good to have backups, independent of which database you use. The transactional paradigm has its benefits and its drawbacks. Many users and application developers depend on the ease with which they can code around problems where an "abort" appears or is necessary, and they may have to do a little more work with MySQL to either think differently or write more. If you are new to the atomic operations paradigm, or more familiar or more comfortable with transactions, do not jump to the conclusion that MySQL has not addressed these issues. Reliability and integrity are foremost in our minds. Recent estimates are that there are more than 1,000,000 mysqld servers currently running, many of which are in production environments. We hear very, very seldom from our users that they have lost any data, and in almost all of those cases user error is involved. This is in our opinion the best proof of MySQL's stability and reliability. Lastly, in situations where integrity is of highest importance, MySQL's current features allow for transaction-level or better reliability and integrity. If you lock tables with LOCK TABLES, all updates will stall until any integrity checks are made. If you only do a read lock (as opposed to a write lock), then reads and inserts are still allowed to happen. The new inserted records will not be seen by any of the clients that have a READ lock until they relaease their read locks. With INSERT DELAYED you can queue insert into a local queue, until the locks are released, without having to have the client to wait for the insert to complete. Atomic in the sense that we mean it is nothing magical, it only means that you can be sure that while each specific up
Re: oracle : The lowdown
Perrin Harkins wrote: > Greg Stark wrote: > > For example, it makes it very hard to mix any kind of long running query with > > OLTP transactions against the same data, since rollback data accumulates very > > quickly. I would give some appendage for a while to tell Oracle to just use > > the most recent data for a long running query without attempting to rollback > > to a consistent view. > > I believe setting the isolation level for dirty reads will allow you to > do exactly that. Oh, silly me. Oracle doesn't appear to offer dirty reads. The lowest level of isolation is "read committed" which reads all data that was committed at the time the query began, but doesn't preserve that state for future queries. So, if you have lots of uncommitted data or you commit lots of data to the table being queried while the query is running you could make your rollback segment pretty big. But, if you can afford Oracle, you can afford RAM. - Perrin
Re: oracle : The lowdown
Greg Stark wrote: > Actually for web sites the lack of transactions is more of a boon than a > problem. We're veering WAY off-topic here, but the fact is you can't guarantee your data will be in a consistent state without transactions or some other way to do atomic updates. Anything short of that suffers from race conditions. So, if that's no big deal for your data (e.g. you're running a message board and who cares if a post gets lost somewhere) then transactions might be considered unnecessary. > For example, it makes it very hard to mix any kind of long running query with > OLTP transactions against the same data, since rollback data accumulates very > quickly. I would give some appendage for a while to tell Oracle to just use > the most recent data for a long running query without attempting to rollback > to a consistent view. I believe setting the isolation level for dirty reads will allow you to do exactly that. You can keep the appendage. - Perrin
Re: oracle : The lowdown
Matt Sergeant <[EMAIL PROTECTED]> writes: > Depends what the business is. If it is a serious business looking for VC I > would actually suspect the inverse is true: MySQL is underkill (I think I > just made that word up) due to its lack of transactions and other advanced > features (yes, these things do mean something in the real world). Actually for web sites the lack of transactions is more of a boon than a problem. Carefully written web pages rarely need complex multiple query transactions anyways. I'm using Oracle now and the single biggest complaint is the unnecessary overhead transactions put in everything even when they're not needed or wanted. For example, it makes it very hard to mix any kind of long running query with OLTP transactions against the same data, since rollback data accumulates very quickly. I would give some appendage for a while to tell Oracle to just use the most recent data for a long running query without attempting to rollback to a consistent view. That said other Oracle features are absolutely essential to web sites: partitioned tables, warm standby databases, hot backups, etc. -- greg
Re: oracle : The lowdown
David Harris wrote: > > Jeff Warner wrote: > > We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and > > and Apache::DBI. Works great, once it is all setup. Our overall > > processing is faster with Oracle too. The lack of transactions and > > views put an immediate end of mySQL once we got into the details of my > > project. > > > > Oracle is overkill for smaller task but you don't have to worry about > > outgrowing it. > > What about PostgreSQL (www.postgresql.org)? It looks like it has transaction > management (commit, rollback) with the whole concurrency control thing. I > don't know if has views. I've got a small project that I am figuring on > using PostgreSQL for, so I'm curious to hear what people might have to say > about it. > > Another option to look at is Solid (www.solidtech.com). They just quoted me > their Solid Embedded Server (their name for a database server) for $2,000 > per CPU. I used their database server a few years ago and it was very nice. > Back then it cost only $200, too... :-) > Has anyone tried this (especially on other distributions/kernel/libc versions): http://www.interbase.com/downloads/summaries/19.html I'd be most interested in your experiences. Of course, InterBase is going open-source, soon. :-)
Re: oracle : The lowdown
Matt Sergeant wrote: > > On Tue, 11 Jan 2000, Joshua Chamas wrote: > > BTW, I have also evaled Sybase, Informix, DB2, SQLServer 6.5, > > Solid, and found Oracle to be the best of all those, but if > > you don't need transactions, go with MySQL... > > Do you mind sharing with me (if not the list) why Sybase lost out to Oracle? > Not going to let me get away with that eh? ... At the time, it was likely that DBD::Sybase didn't support bind parameters, or something stupid like that, maybe lack of support for multiple $sth ... this eval was about 1+1/2 year ago now, so quite dated. It may have been that their licensing was worse too, having me pony up $3000+ up front for a web app, instead of $1200 for Oracle ? I was able to make a successful argument with Oracle that I could monitor "concurrent users" and should have per user pricing for starters (read $Application + $Session in Apache::ASP) Its all a big blur. ;) I think it was Informix & DB2 database quirks that turned me off, I vaguely recall DB2's precise time() data type being too precise and taking up too much storage. SQLServer 6.5 was just weak and locked up way too fast, which supposedly is different with 7.0 -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: oracle : The lowdown
On Tue, 11 Jan 2000, Michael wrote: > > On Tue, 11 Jan 2000, John Armstrong wrote: > > > Hello all- > > > I just got the word from down high that VC's will freak out > > > if they see we are using mysql and now we are looking at an Oracle > > > solution. > > > > > > The product is a mid level mod perl application that will > > > receive ~500,000 hits a day. I want to engineer it to withstand up to > > > 2 million hits per day ( not unique users ). Does anyone have good > > > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > > > would love to hear both sides of the coin. I personally think Oracle > > > is overkill but I don't have any major issues with it. > > > > Depends what the business is. If it is a serious business looking > > for VC I would actually suspect the inverse is true: MySQL is > > underkill (I think I just made that word up) due to its lack of > > transactions and other advanced features (yes, these things do mean > > something in the real world). > > So what's wrong with Postgres ?? > [EMAIL PROTECTED] Nothing except speed. Postgres is great for free projects, and its MVCC is a cool technology in a free database. -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: oracle : The lowdown
On Tue, 11 Jan 2000, Michael Peppler wrote: > You can also use the supported Sybase ASE 11.9.2, which I *believe* > will cost around $20k for a linux/web licence. Have sybase given plans for ASE 12 on Linux yet? I'm hoping to get the text indexing cartridge. -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: oracle : The lowdown
On Tue, Jan 11, 2000 at 02:50:52PM -0800, Ian Mahuron wrote: > Joshua> but if you don't need transactions, go with MySQL... > > Or sub-selects.. I can't live without sub-selects! Sub-selects are high on the to-do list, and the rate that they're advancing MySQL they'll be available quite soonish. Meanwhile they have just implemented in-memory hash-keyed tables that can sometimes be used to workaround sub-selects (via an insert...select followed by a join). Tim.
Re: oracle : The lowdown
Hi all, On Tue, Jan 11, 2000 at 01:20:21PM -0800, Jeffrey W. Baker wrote: > Unfortunately, Oracle support is an ongoing criminal enterprise. > Unless you have the most expensive of all of their support > contracts, and a former Oracle VP on your staff, you will not get > any support period. If you mention Perl, you can forget about > getting bugs fixed, even when the bugs are clearly in the RDBMS and > not the client. You have been warned. Er, the opinions expressed herein are not necessarily... 73 Ged.
RE: oracle : The lowdown
On Tue, 11 Jan 2000, David Harris wrote: > This link was just posted to the IMP list a couple min ago: > > "Low-Cost Unix Database Differences" > http://www.toodarkpark.org/computers/dbs.html > > Stas, this might be a good link to drop somewhere in the guide. This is probably getting pretty far off-topic but I took a look at this and I think the MySQL discussion may be based on 3.21 (3.22 is the current stable version & 3.23 is the alpha) because it says you can't create an index after creating a table (which is no longer true). And a note on its lack of transactions: It is probably possible to code a fairly reasonable simulation of transactions by buffering update/insert commands and using lock tables commands (I'm kind of working on something like that myself, actually). -Dave /*== www.urth.org We await the New Sun ==*/
RE: oracle : The lowdown
Joshua> but if you don't need transactions, go with MySQL... Or sub-selects.. I can't live without sub-selects!
Re: oracle : The lowdown
John Armstrong wrote: > > Hello all- > I just got the word from down high that VC's will freak out > if they see we are using mysql and now we are looking at an Oracle > solution. > > The product is a mid level mod perl application that will > receive ~500,000 hits a day. I want to engineer it to withstand up to > 2 million hits per day ( not unique users ). Does anyone have good > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > would love to hear both sides of the coin. I personally think Oracle > is overkill but I don't have any major issues with it. > My experience with Oracle has been a nightmare. They don't seem to support perl officially, so you have to talk in ways like you are using their native API's. I found a couple bugs that never got fixed, even with being on the phone every day for a week. I don't know what they do with unresolved tar's, but you don't get a call back. I had silver 24x7 support. You might want to consider their gold $100,000 license. Finally, I pushed through the upgrade from 8.0.4 to 8i because of a feature they promised, and they took away incremental backups from rman saying it was now an Enterprise feature, $10,000+ more, so instead having a new 100M incremental update file to backup to tape everynight, I had a new 4G database backup file to backup every night, so that the backup cycles took a few many more hours than it had before. Further the feature that they promised me that I did the upgrade for ended up being "Enterprise", even though no one in sales or tech support knew that before, nor did their promotional materials indicate such. So I went through a brutal database upgrade only to find the system a piece of crap, and Oracle wanting another $10,000 to get it to where it was before. So, I've been migrating a live system to MySQL for a few months, and have found MySQL to be over twice as fast as Oracle, and the support priceless. I used to advocate Oracle, and have been DBA'ing / developing for it for years, but I will be loathe to work with it again. BTW, I have also evaled Sybase, Informix, DB2, SQLServer 6.5, Solid, and found Oracle to be the best of all those, but if you don't need transactions, go with MySQL... Good luck, Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: oracle : The lowdown
Not long ago, Jeffrey W. Baker proclaimed... > Postgres is very slow. In my experience it was never fast enough to > rise to the scale of the project. Oracle can run really quickly with > the right tuning and hardware, Actually, PostgreSQL is also very tuneable. Documentation for PostgreSQL is a bit lacking right now, but I understand there are books in the process of being published and online documentation is growing. IMO, Postgres is the closest thing you're going to get to Oracle without pulling out your checkbook. :-) -=Fozz -- Doran L. Barton <[EMAIL PROTECTED]> Iodynamics LLC -- "Internetworking the masses" http://www.iodynamics.com/>
Re: oracle : The lowdown
Tim Bunce wrote: > > On Tue, Jan 11, 2000 at 01:20:21PM -0800, Jeffrey W. Baker wrote: > > > > Unfortunately, Oracle support is an ongoing criminal enterprise. Unless > > you have the most expensive of all of their support contracts, and a > > former Oracle VP on your staff, you will not get any support period. If > > you mention Perl, you can forget about getting bugs fixed, even when the > > bugs are clearly in the RDBMS and not the client. You have been warned. > > That situation is improving (I have been told). Especially now the > DBD::Oracle can trace OCI calls. Just tell them that you have a > particularly advanced OCI application, and don't mention Perl :-) See, I told you DBD::Oracle was the most advanced :) And Tim Bunce writes it Himself. I suppose this should go over to [EMAIL PROTECTED] -jwb
RE: oracle : The lowdown
Title: RE: oracle : The lowdown Personally, I hate conversions. I've managed and used Oracle databases over 4TB with billions of records. The way I figure it, once I'm up and running on Oracle, I won't worry about the database again. I'm sure there are a number of other valid considerations but for my money, I'll stick with Oracle. Jeff >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 1/11/00, 3:54:18 PM, "David Harris" <[EMAIL PROTECTED]> wrote regarding RE: oracle : The lowdown: > Jeff Warner wrote: > > We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and > > and Apache::DBI. Works great, once it is all setup. Our overall > > processing is faster with Oracle too. The lack of transactions and > > views put an immediate end of mySQL once we got into the details of my > > project. > > > > Oracle is overkill for smaller task but you don't have to worry about > > outgrowing it. > What about PostgreSQL (www.postgresql.org)? It looks like it has transaction > management (commit, rollback) with the whole concurrency control thing. I > don't know if has views. I've got a small project that I am figuring on > using PostgreSQL for, so I'm curious to hear what people might have to say > about it. > Another option to look at is Solid (www.solidtech.com). They just quoted me > their Solid Embedded Server (their name for a database server) for $2,000 > per CPU. I used their database server a few years ago and it was very nice. > Back then it cost only $200, too... :-) > - David Harris >Principal Engineer, DRH Internet Services
Re: oracle : The lowdown
On Tue, Jan 11, 2000 at 01:20:21PM -0800, Jeffrey W. Baker wrote: > > Unfortunately, Oracle support is an ongoing criminal enterprise. Unless > you have the most expensive of all of their support contracts, and a > former Oracle VP on your staff, you will not get any support period. If > you mention Perl, you can forget about getting bugs fixed, even when the > bugs are clearly in the RDBMS and not the client. You have been warned. That situation is improving (I have been told). Especially now the DBD::Oracle can trace OCI calls. Just tell them that you have a particularly advanced OCI application, and don't mention Perl :-) Tim.
Re: oracle : The lowdown
David Harris wrote: > What about PostgreSQL (www.postgresql.org)? It looks like it has transaction > management (commit, rollback) with the whole concurrency control thing. I > don't know if has views. I've got a small project that I am figuring on > using PostgreSQL for, so I'm curious to hear what people might have to say > about it. I was really excited about PostgreSQL before I knew much about databases (not that I know that much now). I checked it out and it seemed cool...but then I experimented with the likes of Sybase and Oracle. There are lots of limitations to PostgreSQL, not the least of which was no referential integrity last I checked (this may have changed). In addition to that, though there were lots of other things that weren't dynamically changable that were in the bigger RDBMs (dropping fields, changing data types on the fly...stuff like that). There was some talk of questionable stability that I heard that made me wary. All in all I have a lot of respect for Oracle the database (not necessarily the company :), and I don't think PostgreSQL is there yet, as much as I would like an open source DB to be. > Another option to look at is Solid (www.solidtech.com). They just quoted me > their Solid Embedded Server (their name for a database server) for $2,000 > per CPU. I used their database server a few years ago and it was very nice. > Back then it cost only $200, too... :-) > > - David Harris I've used Solid in the past as well. It seems more robust, etc than PostgreSQL, but has issues too...some things can be changed dynamically if you add things, but not remove (like fields). It has a weird idea of transactions...you have to do a commit() after doing a select if you want to see the latest data. You can't change table constraints after a table is created (this gets complained about a lot. And finally, there is something funny in the way it syncs data to disk. People who use Linux are constantly applying some patch that changes the semantics of the fsync() system call so that it's essentially non-blocking instead of blocking (like, from what I understand, it should be). I don't know what to make of this issue...it sounds like a gnarly technical problem from the linux kernel archives I've seen it referenced in, and I've even seen Linus denounce that DBs need this sort of functionality at all, although I honestly don't know what the real deal is. Anyway, all of this was with Solid 2.3, and with 3.0 out some issues may be resolved. I'm pretty sure the fsync() stuff isn't (though this may be a Linux issue...it's really hard to tell). Oh, and finally everyone was really pissed at Solid for raising prices like x 10 out of the blue. I'm guessing they lost a lot of customers over it. - Bill
Re: oracle : The lowdown
John Armstrong wrote: > > On this thread, I am seeing a lot of things in the archives hinting > at issues and problems with Apache::Session ( DBI usage ) and high > end DB's like Oracle and SyBase. > > What sort of success is anyone seeing using Oracle/SyBase with > Apache::Session. Apache::Session in a DBI context is crucial to our > development effort so that is a huge factor. > > We are also looking at using Mason but I don't see any problems with > that right offhand. I recommend using mySQL as the datastore for Apache::Session. You may have problems with Oracle, although I haven't checked lately. You will have problems with Sybase, although fixes are available. Apache::Session comes with the source code. MySQL is great for Apache::Session because everything that Apache::Session does is atomic: it doesn't need transactions at the database level. MySQL inserts are very fast because it doesn't (cannot) check referential integrity and the like. Also MySQL's TEXT column type is much easier to use than the Oracle *LOB datatypes, at least when DBI is the interface. Of course you can use mySQL for sessions alongside the Oracle that you use for business data. -jwb
Re: oracle : The lowdown
Take a look at Frontbase www.frontbase.com From what I can see, it does everything that Oracle or Sybase can do and is much more reasonable in price. They're a small company and the support has been excellent. We've outgrown MySQL and are planning to use Frontbase to replace it. At 01:08 PM 1/11/00 -0800, you wrote: > > On Tue, 11 Jan 2000, John Armstrong wrote: > > > Hello all- > > > I just got the word from down high that VC's will freak out > > > if they see we are using mysql and now we are looking at an Oracle > > > solution. > > > > > > The product is a mid level mod perl application that will > > > receive ~500,000 hits a day. I want to engineer it to withstand up to > > > 2 million hits per day ( not unique users ). Does anyone have good > > > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > > > would love to hear both sides of the coin. I personally think Oracle > > > is overkill but I don't have any major issues with it. > > > > Depends what the business is. If it is a serious business looking > > for VC I would actually suspect the inverse is true: MySQL is > > underkill (I think I just made that word up) due to its lack of > > transactions and other advanced features (yes, these things do mean > > something in the real world).
Re: oracle : The lowdown
David Harris wrote: > > Jeff Warner wrote: > > We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and > > and Apache::DBI. Works great, once it is all setup. Our overall > > processing is faster with Oracle too. The lack of transactions and > > views put an immediate end of mySQL once we got into the details of my > > project. > > > > Oracle is overkill for smaller task but you don't have to worry about > > outgrowing it. > > What about PostgreSQL (www.postgresql.org)? It looks like it has transaction > management (commit, rollback) with the whole concurrency control thing. I > don't know if has views. I've got a small project that I am figuring on > using PostgreSQL for, so I'm curious to hear what people might have to say > about it. Postgres is very slow. In my experience it was never fast enough to rise to the scale of the project. Oracle can run really quickly with the right tuning and hardware, and DBD::Oracle is the most advanced DBD in several ways. DBD::Oracle supports Oracle stored procedures, stored procedures which return cursors, and it is fast and robust. Unfortunately, Oracle support is an ongoing criminal enterprise. Unless you have the most expensive of all of their support contracts, and a former Oracle VP on your staff, you will not get any support period. If you mention Perl, you can forget about getting bugs fixed, even when the bugs are clearly in the RDBMS and not the client. You have been warned. Also you might want to tell your VCs to stick it. Just think about it. The minute you let those banker fucks make technical decisions is the minute that your company starts to decline. -jwb
RE: oracle : The lowdown
>From past experiences I'll tell you that PostgreSQL is *dog slow*! We had a search engine with about 10,000 entries in it that was being run on MySQL, moved it to PostgreSQL and *bam*.. even with proper indexing & limiting queries, it took 2-5 seconds to execute a simple query (server was load free). So anyways.. don't waste your time installing PostgreSQL. I've heard good things about Solid.. so maybe you start there. Jeff Warner wrote: > We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and > and Apache::DBI. Works great, once it is all setup. Our overall > processing is faster with Oracle too. The lack of transactions and > views put an immediate end of mySQL once we got into the details of my > project. > > Oracle is overkill for smaller task but you don't have to worry about > outgrowing it. What about PostgreSQL (www.postgresql.org)? It looks like it has transaction management (commit, rollback) with the whole concurrency control thing. I don't know if has views. I've got a small project that I am figuring on using PostgreSQL for, so I'm curious to hear what people might have to say about it. Another option to look at is Solid (www.solidtech.com). They just quoted me their Solid Embedded Server (their name for a database server) for $2,000 per CPU. I used their database server a few years ago and it was very nice. Back then it cost only $200, too... :-) - David Harris Principal Engineer, DRH Internet Services
RE: oracle : The lowdown
On this thread, I am seeing a lot of things in the archives hinting at issues and problems with Apache::Session ( DBI usage ) and high end DB's like Oracle and SyBase. What sort of success is anyone seeing using Oracle/SyBase with Apache::Session. Apache::Session in a DBI context is crucial to our development effort so that is a huge factor. We are also looking at using Mason but I don't see any problems with that right offhand. John- At 4:09 PM -0500 1/11/00, David Harris wrote: >David Harris wrote: > > What about PostgreSQL (www.postgresql.org)? It looks like it has >transaction > > management (commit, rollback) with the whole concurrency control thing. I > > don't know if has views. I've got a small project that I am figuring on > > using PostgreSQL for, so I'm curious to hear what people might have to say > > about it. > >This link was just posted to the IMP list a couple min ago: > >"Low-Cost Unix Database Differences" >http://www.toodarkpark.org/computers/dbs.html > >Stas, this might be a good link to drop somewhere in the guide. > > - David Harris > Principal Engineer, DRH Internet Services Today I sniffed Many dog butts-I celebrate By kissing your face. -Doggie Haiku
RE: oracle : The lowdown
David Harris wrote: > What about PostgreSQL (www.postgresql.org)? It looks like it has transaction > management (commit, rollback) with the whole concurrency control thing. I > don't know if has views. I've got a small project that I am figuring on > using PostgreSQL for, so I'm curious to hear what people might have to say > about it. This link was just posted to the IMP list a couple min ago: "Low-Cost Unix Database Differences" http://www.toodarkpark.org/computers/dbs.html Stas, this might be a good link to drop somewhere in the guide. - David Harris Principal Engineer, DRH Internet Services
Re: oracle : The lowdown
> On Tue, 11 Jan 2000, John Armstrong wrote: > > Hello all- > > I just got the word from down high that VC's will freak out > > if they see we are using mysql and now we are looking at an Oracle > > solution. > > > > The product is a mid level mod perl application that will > > receive ~500,000 hits a day. I want to engineer it to withstand up to > > 2 million hits per day ( not unique users ). Does anyone have good > > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > > would love to hear both sides of the coin. I personally think Oracle > > is overkill but I don't have any major issues with it. > > Depends what the business is. If it is a serious business looking > for VC I would actually suspect the inverse is true: MySQL is > underkill (I think I just made that word up) due to its lack of > transactions and other advanced features (yes, these things do mean > something in the real world). So what's wrong with Postgres ?? [EMAIL PROTECTED]
RE: oracle : The lowdown
Jeff Warner wrote: > We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and > and Apache::DBI. Works great, once it is all setup. Our overall > processing is faster with Oracle too. The lack of transactions and > views put an immediate end of mySQL once we got into the details of my > project. > > Oracle is overkill for smaller task but you don't have to worry about > outgrowing it. What about PostgreSQL (www.postgresql.org)? It looks like it has transaction management (commit, rollback) with the whole concurrency control thing. I don't know if has views. I've got a small project that I am figuring on using PostgreSQL for, so I'm curious to hear what people might have to say about it. Another option to look at is Solid (www.solidtech.com). They just quoted me their Solid Embedded Server (their name for a database server) for $2,000 per CPU. I used their database server a few years ago and it was very nice. Back then it cost only $200, too... :-) - David Harris Principal Engineer, DRH Internet Services
Re: oracle : The lowdown
Matt Sergeant writes: > On Tue, 11 Jan 2000, John Armstrong wrote: > > Hello all- > >I just got the word from down high that VC's will freak out > > if they see we are using mysql and now we are looking at an Oracle > > solution. > > > >The product is a mid level mod perl application that will > > receive ~500,000 hits a day. I want to engineer it to withstand up to > > 2 million hits per day ( not unique users ). Does anyone have good > > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > > would love to hear both sides of the coin. I personally think Oracle > > is overkill but I don't have any major issues with it. > > support. Of course you pay for it. A single web Oracle licence is going to > set you back around $25,000 (as will most commercial databases). If cost is > an issue check out Sybase ASE 11.3 which is free for even commercial use > (no support though) and has been solid for me for nearly a year now. You can also use the supported Sybase ASE 11.9.2, which I *believe* will cost around $20k for a linux/web licence. Michael -- Michael Peppler -||- Data Migrations Inc. [EMAIL PROTECTED]-||- http://www.mbay.net/~mpeppler Int. Sybase User Group -||- http://www.isug.com Sybase on Linux mailing list: [EMAIL PROTECTED]
Re: oracle : The lowdown
> Hello all- > I just got the word from down high that VC's will freak out > if they see we are using mysql and now we are looking at an Oracle > solution. (Um, are these VC's in a position to make an informed decision about which RDBMS to use? What happens when they say "use foo" when foo sucks?) > The product is a mid level mod perl application that will > receive ~500,000 hits a day. I want to engineer it to withstand up to > 2 million hits per day ( not unique users ). Does anyone have good > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > would love to hear both sides of the coin. I personally think Oracle > is overkill but I don't have any major issues with it. Oracle takes longer to connect than Mysql so you should cache DB connections. -- Mark Wagner [EMAIL PROTECTED] Chipmunks roasting on an open fire.
Re: oracle : The lowdown
On Tue, 11 Jan 2000, John Armstrong wrote: > Hello all- > I just got the word from down high that VC's will freak out > if they see we are using mysql and now we are looking at an Oracle > solution. > > The product is a mid level mod perl application that will > receive ~500,000 hits a day. I want to engineer it to withstand up to > 2 million hits per day ( not unique users ). Does anyone have good > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > would love to hear both sides of the coin. I personally think Oracle > is overkill but I don't have any major issues with it. Depends what the business is. If it is a serious business looking for VC I would actually suspect the inverse is true: MySQL is underkill (I think I just made that word up) due to its lack of transactions and other advanced features (yes, these things do mean something in the real world). Go with Oracle. It scales unbelievably, works forever, and comes with lots of support. Of course you pay for it. A single web Oracle licence is going to set you back around $25,000 (as will most commercial databases). If cost is an issue check out Sybase ASE 11.3 which is free for even commercial use (no support though) and has been solid for me for nearly a year now. -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: oracle : The lowdown
Title: Re: oracle : The lowdown We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and and Apache::DBI. Works great, once it is all setup. Our overall processing is faster with Oracle too. The lack of transactions and views put an immediate end of mySQL once we got into the details of my project. Oracle is overkill for smaller task but you don't have to worry about outgrowing it. Jeff >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 1/11/00, 1:54:14 PM, John Armstrong <[EMAIL PROTECTED]> wrote regarding oracle : The lowdown: > Hello all- > I just got the word from down high that VC's will freak out > if they see we are using mysql and now we are looking at an Oracle > solution. > The product is a mid level mod perl application that will > receive ~500,000 hits a day. I want to engineer it to withstand up to > 2 million hits per day ( not unique users ). Does anyone have good > or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I > would love to hear both sides of the coin. I personally think Oracle > is overkill but I don't have any major issues with it. > I am also searching the archives for problem reports but I was hoping > for some anecdotal evidence about the positive or negative of this > move. > Thanks! > John Armstrong > --- > 'Gone With The Wind' is going to be the biggest flop in the history > of Hollywood. I'm just glad it'll be Clark Gable who's falling flat > on his face and not Gary Cooper. > -Gary Cooper, 1938
oracle : The lowdown
Hello all- I just got the word from down high that VC's will freak out if they see we are using mysql and now we are looking at an Oracle solution. The product is a mid level mod perl application that will receive ~500,000 hits a day. I want to engineer it to withstand up to 2 million hits per day ( not unique users ). Does anyone have good or bad stories about using Oracle with mod_perl/DBI/Apache::DBI? I would love to hear both sides of the coin. I personally think Oracle is overkill but I don't have any major issues with it. I am also searching the archives for problem reports but I was hoping for some anecdotal evidence about the positive or negative of this move. Thanks! John Armstrong --- 'Gone With The Wind' is going to be the biggest flop in the history of Hollywood. I'm just glad it'll be Clark Gable who's falling flat on his face and not Gary Cooper. -Gary Cooper, 1938
