Jim Lawrence
accessd at shaw.ca
Thu May 31 17:47:05 CDT 2007
Hi Arthur: As I teeter on the same precipice. My feelings are that the relational database model has reached it maximum capabilities. A couple of good database friends, one who has studied Caché at length and the other that has been working with Spatial GIS data for years and myself would be very interested. Note: The GIS data is current being housed in an Oracle warehouse but there is a complex front-end object modeler from ESRI (http://www.esri.com/) that actually does all the work. Our coffee clutch would be very interested in any O-O design project that you may be planning. Regards Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Thursday, May 31, 2007 3:01 PM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] SQL Server versus Oracle I have worked with MS databases in excess of 1 Tb and that is not your problem. To give Oracle its due, in this respect alone, in Oracle you can create namespaces that correspond to physical drives and that can also respect FKs that span databases (or more exactly, name spaces). MS-SQL cannot do this, sadly. More generally, I would approach the problem using an automobile analogy. 85%+ of what most users require is encompassed in SQL Server and several other alternatives, for zero dollars to many more, depending on vagaries. There is no doubt about it, if what you want is security plus multi-TB capability plus plus plus, Oracle and DB2 are the only games in town. And I say this as a big fan of MS-SQL. There are things that MS-SQL cannot even pretend to do. If these things are on your necessary-list, then MS-SQL falls off your list of contenders. Let's take just a few examples: a) I want 8 databases to tie together, some of which are separated by firewalls etc. I want foreign keys to work across said databases. MS-SQL cannot enforce FKs across db boundaries. Big problem. Oracle can, so from that perspective this is an unimportant issue. Given that our client is wedded to MS-SQL, then what do we do? There are several alternatives, which I won't detail here, but suffice to say that all of them (that I know of) are less than beautiful. b) my principal db of concern is several PB (petabytes). c) my db of concern must install jobs that on schedule grab data from several other databases (for illustration, let's say said databases include one MySQL db, one PostGres db and one Oracle db). I need to grab the new data added to each of these since my last visit. I am well aware that this is not impossible, and in fact not particularly difficult. My point is that inhaling all this foreign data on schedule and guaranteeing the RI of the imports is non-trivial. It can be done, of course. I have done it. That is not the issue that I am attempting to present. The issue is that this is non-trivial. Many hours and many days might be expended making this sort of thing work. I am happy to bill for thousands of hours, but that is beside the point. The customer wants a solution not a description of the problem. That is my current mantra. Back to your topic: Oracle has some serious technology that might be important only in an organization with multi-TB databases, and several of these linked together in a WAN or whatever. But to take just one thing O can do that MS-SQL cannot, look at RI across databases. Expand that to view numerous dbs located who knows where, but which maintain RI. There is NO way to achieve that in MS-SQL. Oracle blazes the relational path, without doubt. Other implementations try to catch up. On the other hand, MS-SQL does 99% of what most customers want to do. Call MS the GM of software. Yes, you can buy an Aston-Martin and if that's what you want, then GM wishes you well, but if you're looking for an inexpensive solution then MS-SQL may be your ticket. (Or not. There remain alternatives such as MySQL and PostGres, which are freely downloadable and can be addressed using ODBC.) It is also true that the era of relational databases may be seeing its sunset. Implementations such as Cache raise the bar, and challenge the precepts that underly Codd's theory and subsequent implementations. I have played with Cache only a little; basically ported a complex app to Cache and run it and discovered dramatic performance improvements. But OTOH there is a whole new suitcase of stuff to lean, and I'm old and I don't have all that many available brain cells left. I'd hate to think of myself as going down, clinging to his precepts. I'd like to pretend that I'm a better person than that, and that presented with a superior alternative, I am willing to junk what I've learned and take the new path. Obviously, there is reluctance, not all of which is bad... I've been led down a few garden paths before, to no avail. Late in life, IMO, Dr. Codd made some statements that I would call questionable. IMO, he didn't perceive the Object problem, nor the GIS problem, in their gory details. That's ok by me. It doesn't mean that he's right, and it doesn't diminish his stature if he's wrong. It happens that I deem him incorrect on these particular two issues, and also one other, which I won't bother to get into now). It is certainly possible to implement an O-O database within a classic relational paradigm, but that isn't really the question. The question, IMO, is whether a db such as Cache can deliver superior performance (along with the assumed reliability etc.) to a SQL-based implementation of same. To test this, we need a complex object model and at least a few million rows of the various objects. It happens that I have a very good model for this test, but it will take me some time to port the data to the Cache db. My particular model concerns the pulp and paper industry. I think I can sketch this one in my sleep, but I am interested to hear from developers who have devoted similar time to particular domains. A. On 5/31/07, Elizabeth.J.Doering at wellsfargo.com < Elizabeth.J.Doering at wellsfargo.com> wrote: > > > Come to find out, I am speaking in 30 minutes about the virtues of SQL > Server 2005 versus those of Oracle. Given that my knowledge of Oracle > could still dance comfortably on the head of a pin, I am frantically > googling up details for my 'speech', and I would love to have your > opinions > > I can easily say that we have already SQL Server and that Oracle is > going to cost us $$$$$ that we hadn't budgeted for. The thing I am most > up against is a contention that 650 users are going to generate more > data in a year or two than SQL Server can possibly hold. I'm of the > opinion that with a normalized database in a call center environment, > users generating 10 or 12 records per call can go for years without > seeing much if any slowdown. Is this accurate? > > Oracle isn't being suggested for the production environment however. > Oracle is being pushed for the REPORTING side of this system, for the 3 > or 4 analysts who will be looking at the long term performance of the > folks in the call center. > > Is this making sense? The production staff can live with SQL Server, > but 3 or 4 analysts need the big bucks spent on Oracle for running their > reports. > > Opinions, please? > > > Thanks, > > > Liz > > > Liz Doering > elizabeth.j.doering at wellsfargo.com > 612.667.2447 > > > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose, or take any action based on > this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation. > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com