Some web site architectural nostrums make good sense while others often seem to be aiming at solving non-existent problems.

About a decade ago I had a development team rife with internal conflict. Our company was a Microsoft Strategic Partner and the CTO mandated that we use SQL Server. This was a very unhappy directive for many of my staff. They demanded Oracle. At the time it was SQL Server 7. The dissidents argued for Oracle because although SS 7 was powerfull enough to run our startup company, they pointed out that the company could grow too big and we would be forced into Oracle. Better to move to Oracle now and avoid problems later, they said.

About that time I was teaching a class in Oracle which gave me an appreciation for SQL Server's superior ease of use. I didn't want to change.

I, being in management, tried to argue for company policy. I said that before the company got too big for SQL Server the product was likely to expand its capabilities. As we now know I was right.

In the late nineties lots of companies started with SQL Server and then moved to Oracle when they out grew it. This became the litany of the "experts". However it stopped being sensible in 2000. After SQL 2000 was released virtually no US company was simply too big for Microsoft's product.

It is my opinion that today applications begun with one DBMS are likely to stay with it indefinitely. I just don't think it makes much sense to build applications so that they can be migrated to another DBMS. I'm sure that this makes sense for someone somewhere, but I find it difficult to imagine that a Beer House based site will ever be migrated.

I understand that the extra complexity of the BLL and DAL in the Beer House architecture are there mostly for pedigogical purposes, even so I'm guessing that very few larger scale projects really need that extra flexibility.

Microsoft products are likely to be around for quite some time. I suspect that any project I'm involved with will not last as long as SQL Server. Therefore building a site or application tied intimately to specific SQL Server features seems safe.

Or maybe I'm all wet?

http://weboperahouse.com

__________________
http://weboperahouse.com
http://www.boyleed.com

I'm sure you'd be surprised how many of us use Oracle. At my day job we have over a dozen distributed Oracle databases linked together. The size is measured in terrabytes. These run on high-end Sun servers using a storage area network and state-of-the-art plumbing all the way around.

And .NET is our primary application development environment, on Windows 2003 servers. It's difficult to hire people to maintain a complex system like this, and I like to see people who have an open mind about other DB platforms.

I also work a lot with SQL Server, but not as part of my day job. I have learned not to be prejudiced one way or the other. Each company has their own set of requirements and legacy technologies. This isn't a "one size fits all" world. When Marco was trying to consider making the architecture flexible to support other DBs he was just trying to leave the door open a bit. It's too hard to fully implement support for more than one DBMS as part of a book website, but it's good for people to think about these things.

Eric

i haven't considered moving the sql onto any other database plateform mainly due to the fact that the hosting companies that i use tend to have either SQLServer (or SQLExpress) or MySQL as the available options.

Hoever, it would be nice to see both an oracle and a MySQL version of the sqlClient classes just to compare them. in fact, i'm sure that the site generator, that i mentioned in apreviuos post, would be ideal for this as it's template based. therefore, you could select your target database platform and get it to fire off the appropriate backend sql and connectivity options based on your selection. in fact, i'm just thinking this 'off the hoof', so may investigate adding this to the feature set (with the consent of lee, the original author).

but academically, as things stand, it would be good to see the three main variants represented in order to mix match as required (could even have a hybrid running with forums coming from sqlserver and articles from oracle etc, etc...)

jimi

http://www.jamestollan.com

The MS Oracle provider is almost identical to their SQL provider, aside from replacing every instance of "Sql" with "Oracle" in their naming convention.

But the much better provider that comes from Oracle has quite a few differences. The main difference being that transactions are tied to the connection rather than the command. This is as it should be, and I've always failed to understand why MS did it wrong. After all, you roll back a transaction on a connection-wide basis. You can't roll back the changes for one command object only!

Another difference is Microsoft's lack of support for Oracle in any of the 2.0 providers. Oracle themselves are only officially introducing this support now, but it's been out unofficially for a year. Microsoft also fails to support Oracle in the server explorer, and they don't let you debug into Oracle stored procedures. Both of these are supported in the Oracle .NET tools.

Eric