May 22, 2005 05:38 PM|m.sean.kelly|LINK
Just wondering what the conclusion was here. Has the proof-of-concept been started? Has work on using DAAB in DNN 3.x been started?
I found an article describing a modification to DAAB that looks promising:
http://www.devx.com/dbzone/Article/20539/0/page/1. The SQL code, whether it is raw SQL or stored procedure calls, is stored in config files. This would mean that the business layer could, theoretically, be database agnostic. Simply replace the config
file and you're done.
This approach assumes that the stored procedures are nothing more than CRUD operations. As soon as anything more complicated occurs in the sprocs, the model starts to break down.
Some might argue that putting more code in the sprocs makes the operations more efficient and reduces latency. And it's true. Sometimes we get significant gains by reducing the number of round trips to the database, or by leveraging the database's set-oriented
processing to munge the data. But adding more processing work to the database server also means that we more quickly run out of CPU on that server. Given the licensing structure for SQL Server, adding more CPUs gets very expensive very quick. So, the more
processing we can move into the business layer, while maintaining acceptable response times, the better off we are; both from the standpoint of being database agnostic and from the standpoint of reducing the total system cost.
One final point on MySql and scalability: MySql Cluster actually has a much better scalability story than MS SQL Server. With MySql Cluster you can have up to 48 servers wired together handling requests. The data is automatically partitioned and replicated
among them. While a similar effect can be achieved with MS SQL Server's distributed partitioned views and replication, it is much more expensive and difficult to implement.
My 2 cents.