SQLServerCentral / Editorials / SQLServerCentral.com / The Wild Fringes of SQL Server Development / Latest Posts

RE: The Wild Fringes of SQL Server Development

Tom Garth — Wed, 03 Dec 2008 14:39:15 GMT

As a VB developer since VB 3, Access was the DB choice. In fact Access was developed just for VB. Other mostly ISAM databases were around and we frequently developed to take existing DOS applications into the windows world. Ad-Hoc query language was the norm.I'll admit that learning T-SQL was not something that I couldn't wait to do. It sort of had to be pushed on me gently, but I did begin writing procedures in SQL Server 7, and it was only a year after that when 2000 was released with it's improved client toolset.I've learned to relish what can be done with T-SQL. As DBarryYoung says, it is foolish not to utilize the built in enforcement rules of the SQL Server database schema design. I would add to that statement that it is foolish when designing an application that requires layered security, to not use SQL Server security utilizing AD or Local Security Groups. Next in the Business Logic train are properly built Stored Procedures that reenforce the schema rules and add a few more where appropriate.I don't do much web design. I'm a VB 2005 / 2008 programmer, and that makes for a good user interface, and is also the last place for additional Business Logic. The versatility and speed of writing VB code allows for easy interaction for enforcing data types, lengths, and the like.I don't like to use infinitives, but a well thought design of an application with the bulk of the design being at the database level, will allow for many modifications, especially when debugging, that (never) have to be redistributed.[b][i]I don't work with many other DB applications these days, but SQL Server is way to powerful to be wasted as just a data repository.[/i][/b]

RE: The Wild Fringes of SQL Server Development

DPhillips-731960 — Mon, 01 Dec 2008 19:45:36 GMT

[quote][b]Andrew Peterson (12/1/2008)[/b][hr]From an architecture approach at the database level, typically you created the db schema based on the business objectives. Now, with the database object abstraction tools, developers come in, use these tools to actually create the db schema, and literally take the stand that they don’t need database architects/DBA’s. The JBOT approach (just a bunch of tables). The problem is that the database schema tends to get ugly, grows in an ugly manner, and is difficult to optimize. (I just finished a project to try to clean up such a mess).[/quote]I have had to deal with just such similar issues. Unfortunately, and I know this is not universal, but most of the young crowd doing web-based application design that I have come into contact with, know little about a database, and do exactly as described above. Some in the .NET world, but far more in the open-source world. The sad truth is they do not see the performance hits until the database is too large to change easily. Trying to argue it is painful... keys, relational integrity, storage and disk allocation, security, etcetera... all seem to be foreign language. One poignant case in particular, even database server specs were at issue."Watch what happens to your performance when you hit the 2 GB mark, given your current setup and implementation.""Nothing will happen."Not long after, "It" happens. Mr. "Nothing-Will-Happen" leaves for another offer. New person is hired... same type, as HR was only told to replace Mr. "Nothing-Will-Happen". Trying to convey what happened and what needs to happen falls again on seemingly deaf ears.Mr. "Status-Quo" says, "It's not the app, nor the implementation, it's the reporting." (You know, the ones actually trying to get data OUT of the system...)He instead decides to implement a 2nd identical server and mirror via log shipping... for the reporting clients to pull on. Writes go to one, reads from the other. Inconsistencies begin to abound. Clients become "concerned" about down time. Some threaten departure.Mr. "Status-Quo" leaves for another offer. 3 more people (all are admins who know how to install said DB platform, and punch command-line statistics only), and an 3rd party off-site vendor monitoring tool are employed to monitor the server health and uptime. Yet a 3rd identical server is also thrown in for good measure. (This boils down to fix it fast and get it up - every time). Root causes not prosecuted. Company rolls through multiple IT department heads, but not a single DBA position implemented, nor even temporarily contracted. Lost opportunity costs are mounting.

RE: The Wild Fringes of SQL Server Development

RBarryYoung — Mon, 01 Dec 2008 15:03:57 GMT

[quote][b]Bob Abernethy (12/1/2008)[/b][hr]And then there are those people who irrationally hide surreptitous dogma...[/quote]Amen to that, brother.

RE: The Wild Fringes of SQL Server Development

dgoes — Mon, 01 Dec 2008 14:11:45 GMT

My approach is to build a Business Layer which is normally a .NET component or web service layer. Behind this I implement the best solution for the problem at hand, n-tier, stored procs, constraints, access to non-SQL stores etc. However for hard core integrity requirements you cannot do better than to correctly use primary keys, foreign keys, constraints, transactions, stored procs etc. Relational databases continue to be the most powerful tool in our development kit but are unfortunately under utilized by large number of developers leading to bad integrity and late projects.

RE: The Wild Fringes of SQL Server Development

Bob Abernethy — Mon, 01 Dec 2008 13:12:38 GMT

And then there are those people who irrationally hide surreptitous dogma...

RE: The Wild Fringes of SQL Server Development

sgardner — Mon, 01 Dec 2008 13:07:10 GMT

[quote][b]rbarryyoung (12/1/2008)[/b][hr][quote][b]sgardner (12/1/2008)[/b][hr]...But we treat the database as a database and try to leverage its strengths. Data does not change, while business rules are very dynamic, so we do not put business logic into the database ever; that stays in the application...[/quote]First, I am going to assume that you meant "the Data Schema does not change" as there are not many databases where the data never changes.Secondly, you do realize that these two sentences are contradictory, right? Keeping all business rules off the database is not leveraging its strengths at all. It may be leveraging [i]your[/i] strengths as an application developer, but not using the built-in RI (referential integrity) features is abandoning one of the principal strengths of relational databases.[/quote]No, I meant that the data does not change: at least in general. We often add to data, append additional information and the like. The core of the data does not change much. To use one of the canonical examples: The PO. The customer information does not change often. Order data is entered and then added to as the order is processed, but again, it does not change. The business rules for processing the orders changes frequently: what the current pricing model is, incentives, discounts, credit etc. These are implemented in the application, not the database. Referential integrity is not a business rule, it is a data integrity rule and part of the relational model. I use it extensively in the relational model of the enterprise, but never make the mistake of thinking that the relational model is the enterprise. I am speaking more about implementing half of the application logic as stored procedures in the database and the rest in the application logic. There are several reasons that I consider this a bad way to develop. The first is that we run across multiple databases, so portability is a huge issue. The second is if half of the business logic is in the db and the other is the application, then there are going to be inevitable cases where the required logic is either missed or duplicated as the system evolves. Keep all like sub-systems together. Third, it makes for much cleaner development and testing; I can test my business logic without worrying about the database and contra-wise. Last, we have import/export requirements to other systems, so we have to keep the model clean and consistent.

RE: The Wild Fringes of SQL Server Development

Anye Mercy — Mon, 01 Dec 2008 12:41:17 GMT

[quote][b]Alexandros A Nipirakis (12/1/2008)[/b][hr]Having developed using both of these extreme paradigms, I can honestly tell you that having your business logic primarily implemented in the database is usually the best way to go. If not completely in the database, then surely within some web service logic that separates the data access and the client. The reason for this is simple, as a developer one must always assume that someone down the line is going to want to talk to your database. Not implementing your business logic at a layer that lends its self to being opened up to other developers (IE, either stored procedures, views, functions, etc. in the database or at the very least with a robust web service api that implements the business logic correctly). One problem I have run into is when developers do not structure their databases correctly (for whatever reason, the concept of a relational database seems to elude many developers). They may make a very complex database with weirdly named columns, without constraints, and of course without any kind of business logic implemented at the database level. When someone comes later and tries to interact with this database (as often will happen) the second developer wreaks havoc on the database because they are not putting the correct data in the places where the original application assumes that they are going to be. What's worse, is that without a good set of database API's for the secondary applications to interact with, the database becomes corrupt because of missed, unimplemented business logic in the secondary or tertiary applications that come down the road. Telling someone -- HEY if you want to create a sales order, call this Web Service, or HEY if you want to create a PO, just call this stored procedure makes it much easier for future applications to use your database. If your application doesn't require this kind of code reusability, then don't use SQL server. Store all the information in a lightweight database (like SQLite or FirebirdSQL) and leave the real database stuff to the pros. Using SQL Server (or Oracle) insinuates that you are making an Enterprise (or at worst professional business level) database driven application. I think if you are going to play with the big boys, then you ought to program like the big boys do. Again, anyone can disagree with me, but I think that we need to jump into the 21st century and understand that our database engines today have the ability to do many things, the best of which is that these new database engines allow us to abstract business logic from within our applications, creating a truly extensible framework with which to create our own applications that can live on for years to come. Aleksei [/quote]Most of what you describe here is not what I would call "business logic". Creating a PO isn't business logic - the rules for determining what to put in the PO is. So you have a stored proc that creates the PO, but your application code will figure out who it's for, what sales rep to assign it to, whether they get a discount based on their sales volume etc. Applications call the logic routine (probably in a service) and then once the logic routine has figured out the details of the PO, it will call the stored proc to actually insert the records.If you make the stored proc handle the business logic as well as just the data access for creating the PO you will have issues if one department uses different business rules to create a PO than another. Your stored proc will either become a spaghetti nightmare of "if PO.Type=X then do these rules" or you will have to create different stored procs for every variation, even though the "shape" of the data is the same. This is the main reason behind separating business logic from data access in the first place.

RE: The Wild Fringes of SQL Server Development

Anye Mercy — Mon, 01 Dec 2008 12:35:21 GMT

[quote][b]samuele.armondi (12/1/2008)[/b]decisions should be taken based on 'this is the best tool for the job' rather than 'this is the tool I know hence it will be better than everything else'.[/quote]QFT. From your lips to everyone's boss's ears...I tend to run down the middle as well. The database controls the data model, and I usually use stored procs for data access, but complex logic tends to stay in the application layer. I get some pushback from those who don't understand databases well and don't like stored procs because they think all code should "be in one place" but luckily I am mostly empowered to do things as I think they need to be done.

RE: The Wild Fringes of SQL Server Development

RBarryYoung — Mon, 01 Dec 2008 12:09:23 GMT

[quote][b]sgardner (12/1/2008)[/b][hr]...But we treat the database as a database and try to leverage its strengths. Data does not change, while business rules are very dynamic, so we do not put business logic into the database ever; that stays in the application...[/quote]First, I am going to assume that you meant "the Data Schema does not change" as there are not many databases where the data never changes.Secondly, you do realize that these two sentences are contradictory, right? Keeping all business rules off the database is not leveraging its strengths at all. It may be leveraging [i]your[/i] strengths as an application developer, but not using the built-in RI (referential integrity) features is abandoning one of the principal strengths of relational databases.

RE: The Wild Fringes of SQL Server Development

sgardner — Mon, 01 Dec 2008 11:09:54 GMT

Reading the original editorial and the followups, I am not too sure where I fall in Tony's taxonomy. On the one hand we use the SQL standard data integrity and association management capabilities where possible. Our application runs across multiple databases, so we stick with Standard SQL. But we treat the database as a database and try to leverage its strengths. Data does not change, while business rules are very dynamic, so we do not put business logic into the database ever; that stays in the application. Our business rules operate against the application object model, which we map with Hibernate. It makes for an application that easier to understand, and is, therefore, more agile.The goal is to use the right tool for the job.

RE: The Wild Fringes of SQL Server Development

Tony Davis — Mon, 01 Dec 2008 09:41:53 GMT

Thanks Andy ;). As is often the case on SSC, the discussion is just as (if not more) interesting than the original post.

Both approaches have their place, though I would have to say that it often seems like you have to "fight harder" for a more database-oriented approach. Grant summed up well one of the main points I was trying to make: people tend to latch on to the way Microsoft has built a certain application, and that way quickly becomes "the only way" to do it.

RE: The Wild Fringes of SQL Server Development

AndyD_is_not_a_number — Mon, 01 Dec 2008 08:53:22 GMT

Thanks for the editorial Tony, it's not everyday that I get to read phrases such as "surreptitiously hide irrational dogma" :hehe:Andy

RE: The Wild Fringes of SQL Server Development

randy.witt — Mon, 01 Dec 2008 08:34:20 GMT

These posts have been very interesting to read.For our in-house development, Visual FoxPro has been our primary development tool, although Microsoft's actions have pushed us to move toward and become more fluent in both SQL Server and .NET. One very good outcome of using Visual FoxPro, is that it required all of our developers to become knowledgeable about both coding and databases. (Also, for non-web-based development, Visual FoxPro is far more RAD for major applications than anything .NET.)Coming from that background and perspective, we would definitely gravitate toward using the database for all it's worth. Why spend so much for SQL Server licensing (FoxPro requires no user licenses, only developer licenses), if all you're using it for is "dumb databases"? (We have hundreds of database users, and our combined, one-time-only, software cost is less than $3,000 for all our Visual FoxPro licenses - try a cost/benefit analysis of that, to hundreds of SQL Server CAL's, server licenses, etc.!) We have SAN's and other backup strategies, so purchasing SQL Server for that purpose isn't merited either. So, for us, the route looks to be setting up as much as seems effective in SQL Server using stored procedures, and developing middle-tier business objects to interface with those. However, I can understand, that if you're developing software to sell (instead of in-house development), that it simplifies some things for you if you only focus on the application code and use a "dumb database". If you can assume that your customer already has invested in SQL Server, you don't have a need to justify the cost of the database licensing.Best wishes,Randy

RE: The Wild Fringes of SQL Server Development

Tim Mitchell — Mon, 01 Dec 2008 08:20:00 GMT

Good article. I've found this case to be true in purchase applications and not just in-house development. I've gone to blows with more than one vendor after their finding that their security scheme involved granting DBO rights to every user in the database, and then "handling security" in the app.

RE: The Wild Fringes of SQL Server Development

GSquared — Mon, 01 Dec 2008 08:12:23 GMT

Good article.I've done a relatively extreme version of "all the rules and logic in the database", and a middle-of-the-road version, where some of the logic and rules are in the db and some are elsewhere. Of the two I've worked with, the first was by far the easiest to develop for. And not just for me, but also for the team that was doing the web pages and reports and such.I haven't been in a situation where all the rules and logic were in the "business layer", so I can't speak for that model.The major advantage to having all of it in the database was that all applications had the same rules consistently (we had multiple dev environments and several applications). Another significant advantage was that we had one place to look if we needed to debug or change a rule. Didn't have to worry about, "is it in the database or in the applications?" Had a dozen applications, but could change the rules for all of them by changing the rules in one place.If I ever work in a business where the business rules never change, that won't matter much. But I don't think there's ever been such a business, or, if there was, it probably lasted all of 1 week.

RE: The Wild Fringes of SQL Server Development

Andrew Peterson-472853 — Mon, 01 Dec 2008 07:30:36 GMT

I have seen both sides, and its fair to say the answer is in the middle. And as many have said, the real key is to understand both your business objectives and the strengths and weaknesses of the entire application stack. Developers don’t really like to deal with database stuff, and out of this came the object abstraction tools like MyGeneration, EntitySpace, NHibernate, Hibernate, etc. The modern day developers like to think in terms of objects, and using these tools to add an object layer to the database makes development much easier. And using the UML approach, they like to have the database tables support the higher level objects.By the way, EntitySpace, which is a very nice product (builds on top of MyGeneration) will generate stored procedures for the typical CRUD processes – very nice. [much better than NHibernate]From an architecture approach at the database level, typically you created the db schema based on the business objectives. Now, with the database object abstraction tools, developers come in, use these tools to actually create the db schema, and literally take the stand that they don’t need database architects/DBA’s. The JBOT approach (just a bunch of tables). The problem is that the database schema tends to get ugly, grows in an ugly manner, and is difficult to optimize. (I just finished a project to try to clean up such a mess).I have found the best approach is to derive the db schema first, from the business objectives, and then use the Object abstraction tools to access the database - but not create it. The business rules/logic can be in either place, based on the business driven goals.The object tools are great, if used wisely. But they need to be managed, and not used blindly. And realize that they have limits. Like any tool, you need to read the manual.

RE: The Wild Fringes of SQL Server Development

Alexandros A Nipirakis — Mon, 01 Dec 2008 07:06:24 GMT

Having developed using both of these extreme paradigms, I can honestly tell you that having your business logic primarily implemented in the database is usually the best way to go. If not completely in the database, then surely within some web service logic that separates the data access and the client. The reason for this is simple, as a developer one must always assume that someone down the line is going to want to talk to your database. Not implementing your business logic at a layer that lends its self to being opened up to other developers (IE, either stored procedures, views, functions, etc. in the database or at the very least with a robust web service api that implements the business logic correctly). One problem I have run into is when developers do not structure their databases correctly (for whatever reason, the concept of a relational database seems to elude many developers). They may make a very complex database with weirdly named columns, without constraints, and of course without any kind of business logic implemented at the database level. When someone comes later and tries to interact with this database (as often will happen) the second developer wreaks havoc on the database because they are not putting the correct data in the places where the original application assumes that they are going to be. What's worse, is that without a good set of database API's for the secondary applications to interact with, the database becomes corrupt because of missed, unimplemented business logic in the secondary or tertiary applications that come down the road. Telling someone -- HEY if you want to create a sales order, call this Web Service, or HEY if you want to create a PO, just call this stored procedure makes it much easier for future applications to use your database. If your application doesn't require this kind of code reusability, then don't use SQL server. Store all the information in a lightweight database (like SQLite or FirebirdSQL) and leave the real database stuff to the pros. Using SQL Server (or Oracle) insinuates that you are making an Enterprise (or at worst professional business level) database driven application. I think if you are going to play with the big boys, then you ought to program like the big boys do. Again, anyone can disagree with me, but I think that we need to jump into the 21st century and understand that our database engines today have the ability to do many things, the best of which is that these new database engines allow us to abstract business logic from within our applications, creating a truly extensible framework with which to create our own applications that can live on for years to come. Aleksei

RE: The Wild Fringes of SQL Server Development

samuele.armondi — Mon, 01 Dec 2008 06:54:49 GMT

Re Jack's point on triggers - watch out for a forthcoming article on generic triggers, which will (hopefully) address some of the business layer/database logging debate.PS - this will be my first article for SSC, so please be gentle with me ;)Regards,SAM

RE: The Wild Fringes of SQL Server Development

Jack Corbett — Mon, 01 Dec 2008 06:51:19 GMT

I agree with Tony, and others, that you need to evaluate all options and choose those which create the best application. I used to be a do it all in the DB guy, and frankly, that is still easier for me, but I have learned that many times complex business logic is better handled in a Business layer.Of course, in my mind, stored procedures are the way to go for data access for security purposes. Not because you can't secure an application, but because exposing tables directly means users can use Access, Excel, etc..., to read and manipulate data. This is also why I use triggers for logging changes to data, even if just to protect me from an ad-hoc update/delete that I might run.

RE: The Wild Fringes of SQL Server Development

samuele.armondi — Mon, 01 Dec 2008 06:21:32 GMT

I agree with Blandry - to be considered anything more that an averagely good developer more is needed that knowledge about your subject area. There is a need for a wider appreciation of how things work together - different technologies, front, middle and back end, etc... decisions should be taken based on 'this is the best tool for the job' rather than 'this is the tool I know hence it will be better than everything else'.In my experience, far too many developers think they are great because they know the .Net framework inside out, or know c++ inside out but have absolutely no knowledge (or indeed wish to have any) of the technologies for the back end, how they work, how to use them, which are best suited for what, etc. Technology is moving too fast to only know one side of it!

RE: The Wild Fringes of SQL Server Development

Grant Fritchey — Mon, 01 Dec 2008 06:16:47 GMT

I think you've hit the nail on the head here Tony. I don't agree with either of the wild fringe groups. I think that well designed apps take advantage of strengths in the areas of development that best benefit the business problem, not simply use tool X or paradigm Y to develop the system. Unfortunately, I'm now working on a pretty major undertaking that is adopting, whole-heartedly, one of the wild fringe group approaches. We no longer have a database. We have an information persistance layer. Funny thing is, it's still on a relational database management system, SQL Server. I don't understand how ignoring the database will make any issues with it go away?You mentioned how Microsoft is causing the problem. Part of the issue coming out of MS are the apps they're developing. One of the VP's in charge of about half our development teams keeps pointing at how MS developed their CRM application. It's largely, but not completely, a dumb database. He just keeps saying that if MS does it, it must be OK. It's hard to argue with that except to point out that the system, while it doesn't use stored procedures, has tons of code on the database in encrypted views that do a lot of the work and it has a clearly defined data model that drives the engine... It's all falling on deaf ears because there is a hefty percentage of developers that believe the days of having to deal with all that messy TSQL stuff and confusing normalization are behind them. I just don't see it.

RE: The Wild Fringes of SQL Server Development

blandry — Mon, 01 Dec 2008 06:10:46 GMT

I suppose its my age and just having been in this business way too long, but I never thought I would work long enough, let alone live long enough, to hear tech people talking about the data layer removed from the application, or vice-versa. I suppose this is also why there are larger numbers of developers I have not hired over this last decade - mainly because I have been stunned at how many know only one side of that coin. Still, I find this really bizarre to even listen to!The age of dBase (and on to Visual FoxPro) was a good one. You had to know code, and you had to know data and how to make the two work together. Later, as VFP became more useful with SQL backends, it was a rather simple and smooth transition to be able to stay with a familiar application product, and get the muscle of a rich and powerful data backend.Now this editorial, these times, suggest what? Do developers sit around pondering great applications without any clue how the data backend might work? Do SQL DBAs think about great interfaces to work with their data, if only they knew how to code?Yikes... This seems like a giant step backwards! Worse, its like going to a baker who will make a cake, and then tell you you need to find a frosting specialist to finish it. Hardly progess. The more we break up what used to be "a developers knowledge base", the more we cripple ourselves - thats my take.

RE: The Wild Fringes of SQL Server Development

Andy Warren — Mon, 01 Dec 2008 05:22:39 GMT

I like the comment about a solution needing to be better than the orthodox solution. Too often an alternative is adopted without baking the whole cake.As for the dumb database, I'd hate to see us go back to dBase, or as more likely, MySQL. As a DBA I'd like to see developers use the platform, but if all they want is a data store that's ok too. I suspect over time they are going to want to use those other 'extra' features than seem frivolous in the beginning.I blame MS for a good bit of this confusion. It's a combination of not explaining loudly enough that best practices aren't always best and not tiering their recommendations (ie, for 1-10 users do this, for 10-100 users do that, or something along those lines).It's part our fault too. Too much dogma, too much rigidity, not enough thinking, and few DBA's have written data access code to understand the work involved. Equally it's the fault of developers, who think that any time spent on data access is wasted, when the data is arguably the only thing out of their effort that matters?It's a subject that both intrigues, infuriates, and exasperates me! It goes back to whether we agree that the orthodox solution is the minimum requirement, and I don't think we (DBA vs Developer) agree on that at all.

RE: The Wild Fringes of SQL Server Development

Derek Dongray — Mon, 01 Dec 2008 05:15:57 GMT

From my experience, a lot of the 'data dump' brigade are developers (particularly web) who have written front ends for other databases (e.g. MySQL) and hence adopt a 'lowest common denominator' approach. That is, they assume that the database server is unlikely to be able to do something, so if you can do it in the application then do so.

RE: The Wild Fringes of SQL Server Development

IceDread — Mon, 01 Dec 2008 02:50:31 GMT

I have not been around that much to notice the two camps that the author is talking about but I can see the points.Where I have been for the last two years, we use sql a lot and .net a lot. We use each platform where we think it is best and we do not really have any sides of sql peeps or .net peeps. Most here does both sql jobs and .net jobs at the same time and everyone has some responsibility areas. Then we have network admins etc responsible for the hardware.

RE: The Wild Fringes of SQL Server Development

samuele.armondi — Mon, 01 Dec 2008 02:29:34 GMT

Well... great editorial, I'm surprised it didn't spark off more comments!!From a personal point of view, I use Nhibernate/Active Record an awful lot, so would fall under the 'Dumb Database' brigade. At the same time however, there are significant portions of my application which would just require too much querying/coding only using NHibernate/ActiveRecord, so I tend to implement those as either stored procs or views which I then access through my middle layer.The great benefit is that front-end developers don't need to know the data model, and I can make changed to the data model (such as splitting tables, etc) without any major repercussions to anyone. The downside is of course that the middle layer code needs direct table access, and performance is not as good as a pure stored proc/ado .net solution would be. However, for most of our applications these are things I can get around with auditing, proper permission setting and a streamlined middle layer.In conclusion, I have to agree with Tony's comment:[quote]I am wary of this sort of "best practice" advice. It is usually a device to surreptitiously hide irrational dogma, or else just a vapid reflection of "what Microsoft says". It's the sort of received wisdom that can stifle creativity and innovation.[/quote]There is always room for improvement, and both camps will argue that their way is better - I am quite happy treading a nice easy [path down the middle :PRegards,S Armondi

RE: The Wild Fringes of SQL Server Development

Paul Hunter — Thu, 27 Nov 2008 16:49:10 GMT

Hurray Tony! If the database is to be nothing more than a data dump then the data dump crowd could (should?) use a simple structure such as the dBase file structure. Why would you want to buy a Ferrari if you only plan to drive it at 20 mph (that's 30 kph for you continental types).The only rule that a developer should [i][b]always[/b][/i] follow is that you should [i][b]always[/b][/i] keep your options open. Do the right work where the most benefit can be achieved.

The Wild Fringes of SQL Server Development

Tony Davis — Thu, 27 Nov 2008 12:35:07 GMT

Comments posted to this topic are about the item [B]The Wild Fringes of SQL Server Development[/B]