Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

The Wild Fringes of SQL Server Development Expand / Collapse
Author
Message
Posted Thursday, November 27, 2008 12:35 PM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Tuesday, August 19, 2014 12:33 PM
Points: 569, Visits: 1,015
Comments posted to this topic are about the item The Wild Fringes of SQL Server Development
Post #609957
Posted Thursday, November 27, 2008 4:49 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 9:55 AM
Points: 201, Visits: 404
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 always follow is that you should always keep your options open. Do the right work where the most benefit can be achieved.



--Paul Hunter
Post #610010
Posted Monday, December 1, 2008 2:29 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 3, 2010 9:19 AM
Points: 140, Visits: 192
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:
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.


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 :P

Regards,
S Armondi
Post #611088
Posted Monday, December 1, 2008 2:50 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, June 3, 2014 8:16 AM
Points: 295, Visits: 1,011
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.
Post #611092
Posted Monday, December 1, 2008 5:15 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, February 18, 2014 7:14 AM
Points: 1,344, Visits: 1,983
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.


Derek
Post #611205
Posted Monday, December 1, 2008 5:22 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Tuesday, August 12, 2014 10:53 AM
Points: 6,783, Visits: 1,876
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.


Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #611211
Posted Monday, December 1, 2008 6:10 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, May 7, 2012 9:23 AM
Points: 304, Visits: 716
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.


There's no such thing as dumb questions, only poorly thought-out answers...
Post #611250
Posted Monday, December 1, 2008 6:16 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 4:21 PM
Points: 15,630, Visits: 28,017
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.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #611255
Posted Monday, December 1, 2008 6:21 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 3, 2010 9:19 AM
Points: 140, Visits: 192
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!
Post #611259
Posted Monday, December 1, 2008 6:51 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 1:20 PM
Points: 11,219, Visits: 12,976
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.




Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #611282
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse