Wtf in development. very unorthodox use of sql server



  • <font color="#191970">The developers at my company are considering a very unorthodox approach to web design and I was wondering what everyone here thought of it.

    They want to move the business logic layer and the presentation layer into sql server.

    This means that most of the html the code for the application will be generated from sql server. Forms, Controls, Tables, Headers, etc will be generated using a merge template system developed in sql server. All the templates will be stored in another database and managed through a simple interface developed in vb.net. Rather then use .net controls they are going to write sql functions to produce the html for combo boxes, input boxes, paging, etc.

    They argue that it will be faster and much more simple to modify, backup, and deploy because every thing will be in one place and they can access it all remotely. Basically the only thing asp.net will be used for is to connect to the database and get the page requested.

    Has anyone else tried this and failed? I need some reason to argue against this!

    I've tried to say that it will be much slower, but they proved me wrong by showing some speed tests. Using the example they had, sql produces dynamic web pages much faster. The reason for this is that there are no thick .net controls for it to manage. All it does is merge the data from its own server into the html template.

    They also said that they can port the the website to different webservers (php, classic asp, etc) with out much work at all. In other words, they don't want their system to be affected by new versions of .net anymore. They complain that some of their other applications are working in a hybrid state and it is a pain to manage. They don't have the time to port everything over to a new version of .net all the time.

    I think that the memory usage is going to go through the roof because sql server will be doing nothing but replacing/ merging text data. They argue that if that happens they can just put the business logic and the presentation layer on another sql server box.
    anyway, maybe you guys can help me save this situation from a front page WTF!</font>



  • The only plus I can think of is no .NET controls may mean more compatibility with browsers.  Even so I have been told there are other ways to do that too. 

    There are probably many bad angles on this... here's a few:

    • Because you have the HTML in the database, it'll be harder if not impossible to use any content management.  You'll be remaking those tools.   And you just turned something simple into a much more complicated task.
    • Usually developping reports with HTML is a lot harder than anything using any tools that do it for you.
    • DBAs are usually a lot more expensive than ASP programmers.
    • You still have to port different versions of SQL Server.  And it'll hit harder.  And you're still using a product embedded in the OS, so when you need to upgrade OS you'll need to upgrade that too.  Maybe you shouldn't use something embedded in the OS?
    • You've basically made the most expensive piece of hardware and the hardest to upgrade and scale, the database, do all the work.  I hope you don't need to support lots of users...
    • If you want to avoid .NET controls you don't need to use that.  Just don't use .NET controls and write HTML in ASP.  And avoid just about all the disadvantages above.


  • I think they'd end up walking right into a horrifying minefield of XSS vulnerabilities. You can't HTMLEncode the data coming back from SQL Server if it includes HTML markup that you need to preserve. HTML and script injection would be woefully easy. The only way around that would be to implement an HTMLEncode UDF on the database server itself, but don't tell the devs that, or they'll think their horribly flawed development model might just be secure enough if they were to do it. ;-)

    Oh, and scalability would pretty much fall to pieces, since you'd need another web server AND another database server just to add another host to the farm if you wanted any good performance increases, I'd think. Judging from the price of SQL Server, you probably don't want to do that.

    Let your web servers do the heavy lifting, and keep the database doing lightweight data management procedures.
     



  • I don't think any of the concerns you cite are really going to be an issue (speed, memory), but rather it's just an unmaintainable brain-raping horror. A shambling corpse of a web application framework. It also sounds like your guys know SQL and don't want to be bothered with stretching their brains to learn anything else.

    Just wait until they are trying to incorporate SQL-generated Javascript into the app, and watch one of them [i]have a stroke[/i].



  • Both of the people above have made good points.  My first thought was that the database is going to get hammered.  It sounds like everytime the user clicks on anything they will require a huge amount of work to be done in the database.  Will this scale up very well?

    How many users would you estimate will be using this application at any one time?  How many individual pages will make up the UI, and is the application otherwise data intensive?

     And please, if your efforts to talk them out of this fail, let us know how this is going in a few months!!
     



  • My WTF co. uses the same approach, well almost.

    The presentation layer is on an app server though.

    The first thing that is a cause of worry is the cost of db server licenses.

    App server licenses are cheaper across a server farm than db server licenses (my co's project requires oracle licenses).

    A serious load test will reveal lots about the feasibility of this method. (Now you know why I consider my place to be WTF).



  • [quote user="Belcat"]

    The only plus I can think of is no .NET controls may mean more compatibility with browsers.  Even so I have been told there are other ways to do that too. 

    <snip>

    • If you want to avoid .NET controls you don't need to use that.  Just don't use .NET controls and write HTML in ASP.  And avoid just about all the disadvantages above.

    [/quote]

    Care to give an example of why you should "avoid .NET controls" and why they cause browser incompatability?  I also suspect that you meant to write "avoid some some .NET control" and not imply "all" like you did, but who knows?



  • ok I'm going to buy a gun and start shooting soon! 

    here are more of their arguments... enjoy.

    "It won't be all that hard to maintain html code because they can continue to use vs, dream, or even front page and use the vb interface to upload the template to the database.  This will make it easy for the web designers (who don't know .net) to integrate their designs"

    "the page logic is simple.  Just parse this template and stuff that into the website wrapper (header and footer) template. "

    "this is exactly what sql report services is doing."

     "We are fed up with having to deploy and roll back dlls or fix problems late at night on production on spot "

    "the more layers you have the more you have to maintain. "

     "in five years we don't want to have every version of visual studio installed on our machines just to support all our web applications."

    "we will code this in a very clean and efficent manner so that it will be easy to maintain"    

     



  • [quote user="Jeff S"][quote user="Belcat"]

    The only plus I can think of is no .NET controls may mean more compatibility with browsers.  Even so I have been told there are other ways to do that too. 

    <snip>

    • If you want to avoid .NET controls you don't need to use that.  Just don't use .NET controls and write HTML in ASP.  And avoid just about all the disadvantages above.

    [/quote]

    Care to give an example of why you should "avoid .NET controls" and why they cause browser incompatability?  I also suspect that you meant to write "avoid some some .NET control" and not imply "all" like you did, but who knows?

    [/quote]

    The OP:

    [quote user="Kev777"]<font color="#191970">Using
    the example they had, sql produces dynamic web pages much faster. The
    reason for this is that there are no thick .net controls for it to
    manage. All it does is merge the data from its own server into the html
    template.</font>
    [/quote]

    The theory is that .Net controlls are causing the slowdown.  Based on that assumption, switching to plain-old html is the way to go.  That does not necessitate shoving said HTML in the database.   If cross-platform compatibility is really an issue (which I very much doubt -- since when has anyone ever written an app that supposed to run in both ASP and PHP?) then they can work up a cross-platform templating system.  Yet again, there's no need to put this in the database.



  • [quote user="kuroshin"]

    My WTF co. uses the same approach, well almost.

    The presentation layer is on an app server though.

    The first thing that is a cause of worry is the cost of db server licenses.

    App server licenses are cheaper across a server farm than db server licenses (my co's project requires oracle licenses).

    A serious load test will reveal lots about the feasibility of this method. (Now you know why I consider my place to be WTF).

    [/quote]

     ok they would rather put money in to more sql servers and upgrade hardware then pay a developer for the time it will take to develop each new application.  Again they think that this method will save them huge amounts of time in deployment and development.  

    anyway...  not much I can do because  the two of them are already having an orgasm developing it.     

     

     



  • ...



  • [quote user="merreborn"][quote user="Jeff S"][quote user="Belcat"]

    The only plus I can think of is no .NET controls may mean more compatibility with browsers.  Even so I have been told there are other ways to do that too. 

    <snip>

    • If you want to avoid .NET controls you don't need to use that.  Just don't use .NET controls and write HTML in ASP.  And avoid just about all the disadvantages above.

    [/quote]

    Care to give an example of why you should "avoid .NET controls" and why they cause browser incompatability?  I also suspect that you meant to write "avoid some some .NET control" and not imply "all" like you did, but who knows?

    [/quote]

    The OP:

    [quote user="Kev777"]<font color="#191970">Using the example they had, sql produces dynamic web pages much faster. The reason for this is that there are no thick .net controls for it to manage. All it does is merge the data from its own server into the html template.</font>[/quote]

    The theory is that .Net controlls are causing the slowdown.  Based on that assumption, switching to plain-old html is the way to go.  That does not necessitate shoving said HTML in the database.   If cross-platform compatibility is really an issue (which I very much doubt -- since when has anyone ever written an app that supposed to run in both ASP and PHP?) then they can work up a cross-platform templating system.  Yet again, there's no need to put this in the database.

    [/quote]

     I agree with you on this.   But their argument is that they are sick of dlls, aspx files, and vb files.    They want as few of those as possible.  The fewer lines of code the better.   They argue that using the .net controls actually creates more code then simply writing a basic html based form.   

     anyway.  debuging this shit is like going back to notepad days of classic asp.   That is why I'm already considering the ak47 over a 22. 



  • It will be hard to maintain all of that HTML code, and now you have absolutely no possibility of using Source Control.  Someone makes a change and you now have no version history, because once you COMMIT, that's it.

    Where do you put images?  If you said "a binary column in the table" then you need to be shot, because that takes up a lot more space.

    SQL server licenses are much more expensive than Application Server licences.

    The page logic looks simple, but parsing will increase a lot of load on the database server.

    SQL report services is using a presentation layer in the SQL report services application/service, not directly from the database.  You're storing all of your markup in the database.  It's not the same.

    If you're fed up with rolling back DLLs, I hope you enjoy your first database restore when someone borks an important page...they take MUCH longer.

    The more layers you have the more you have to maintain--this is correct.  However, different people can maintain different layers, meaning you don't have to be a dba to make changes to the system.

    You can port a version of the solution to the next version of Visual Studio. You can take the code with you and rewrite WTF portions along the way.  Good luck moving it to another database server.  SQL server 2005 is very different from SQL server 2000.

    You say that you will code this in a clean and efficient manner, but that never works in the real world when a client moves your deadline 2 weeks earlier, and now you have to hack it to get it out.

     

    Kev, I'd quit if they don't start seeing the light by this point.



  • It all comes down to goals.  If their goal is to get rid of dlls, aspx files, and vb files then they are doing that.  If their goal is to make a good product then they need to think about what happens when that product gets popular.  While their approach does technically work (as far as I understand), it doesn't scale well.  If they worry about using all versions of VS then tell them to stick to one.  You just have to get them to define a goal, make sure they want that goal, and then help them understand how best to acheive that goal.  If that goal involves getting rid of files, then start looking at another job because that one won't last long.  I'm not aware of any companies that made it big by getting rid of a few files.



  • Oh boy oh boy.

    The purpose of separating storage, logic and presentation layers is to eliminate shear between them, if any one of them changes.

    What happens when a customer (or designer) wants one word in the web page to be changed?

    What if you need the web page to be in more than one language?  Yeah, I know, "we'll never need to do that."  If I had a dollar for every time I've heard that....

    Maintenance, as others have said, is going to be a nightmare.  There is no such thing as "we'll keep it clean."  No one in the universe can keep it "clean" enough to make maintenance even remotely manageable.  Any maintenance is guaranteed to move at a snail's pace, and it will not take more than a few months for the thing to collapse under its own weight as the maintenance requests pile up.

    Premature optimization is the root of all evil.  Have any of these people actually *used* the World Wide Web?  On a busy day, a DNS lookup alone can take several seconds.  Stuffing everything into the database *might* make it go faster.  Will the milliseconds saved by abusing the database that way make a noticeable difference?

    Just what sort of comments will be present if all the logic is in the database?  What about good things like inheritance, encapsulation, and abstraction? 

    I think this attitude is probably the second leading cause of WTFs (the leading cause is ignorance):  "I know a better way than what the rest of the world is doing."  They really don't, of course.  Doing this with the database is neither novel nor clever. Kev's company is not the first to think of it.  Everyone else thought of it, and they immediately understood what a horrifically bad idea it is.  When you want to do something differently from the rest of the world, it's a good idea to look into whether the rest of the world knows something you don't.



  • [quote user="Kev777"][quote user="merreborn"][quote user="Jeff S"][quote user="Belcat"]

    The only plus I can think of is no .NET controls may mean more compatibility with browsers.  Even so I have been told there are other ways to do that too. 

    <snip>

    • If you want to avoid .NET controls you don't need to use that.  Just don't use .NET controls and write HTML in ASP.  And avoid just about all the disadvantages above.

    [/quote]

    Care to give an example of why you should "avoid .NET controls" and why they cause browser incompatability?  I also suspect that you meant to write "avoid some some .NET control" and not imply "all" like you did, but who knows?

    [/quote]

    The OP:

    [quote user="Kev777"]<font color="#191970">Using the example they had, sql produces dynamic web pages much faster. The reason for this is that there are no thick .net controls for it to manage. All it does is merge the data from its own server into the html template.</font>[/quote]

    The theory is that .Net controlls are causing the slowdown.  Based on that assumption, switching to plain-old html is the way to go.  That does not necessitate shoving said HTML in the database.   If cross-platform compatibility is really an issue (which I very much doubt -- since when has anyone ever written an app that supposed to run in both ASP and PHP?) then they can work up a cross-platform templating system.  Yet again, there's no need to put this in the database.

    [/quote]

     I agree with you on this.   But their argument is that they are sick of dlls, aspx files, and vb files.    They want as few of those as possible.  The fewer lines of code the better.   They argue that using the .net controls actually creates more code then simply writing a basic html based form.   

     anyway.  debuging this shit is like going back to notepad days of classic asp.   That is why I'm already considering the ak47 over a 22. 

    [/quote]

    They really should consider learning ASP.NET.  You write much less code if you know how to use it properly.  Sounds like you've got a bunch of scripters and web designers over there and no one who actually knows how to program. That is actually the biggest drawback with ASP.NET -- only someone who really knows how to program and understands concepts like classes and inheritence and libraries and all that actually ever uses it properly.  Everyone else just treats it like a big bunch of ASP pages and include files.

     



  • [quote user="Cotillion"]It all comes down to goals.  If their goal is to get rid of dlls, aspx files, and vb files then they are doing that.  If their goal is to make a good product then they need to think about what happens when that product gets popular.  While their approach does technically work (as far as I understand), it doesn't scale well.  If they worry about using all versions of VS then tell them to stick to one.  You just have to get them to define a goal, make sure they want that goal, and then help them understand how best to acheive that goal.  If that goal involves getting rid of files, then start looking at another job because that one won't last long.  I'm not aware of any companies that made it big by getting rid of a few files.
    [/quote]

    By the way -- they should know that visual studio is not in any way required to write ASP.NET pages.  You can use notepad. All you need is IIS and the .net framework.  If you want intellisense and designers and all that, sure you'd like to use VS, but it is not required in any way.

    I suspect that if you removed Visual Studio from every developer's machine in your company, and forced all developers to use nothing but notepad to write their pages, but trained them all *properly* on using ASP.NET and how to *program* as opposed to script, they would be far more productive and happy rather than implementing some crappy made-up framework with everything stored in SQL Server and writing code that amounts to massive include-and-search-and-replace scripts.  I mean this in all seriousness.  Notepad only development would work far better than what they are proposing.

    My advice, as always: consider learning how to use the tools you have properly before you decide whether or not they are worth your while.   

     



  • if portability is a concern, perhaps something like C & XML should be the processing & storage concern...  [nearly] every system has a c compiler and XML is system independent.  then there's version control capabilities, data backups could even be done with some sort of diff files, and there'd be just one speedy, compiled index file to handle the universe.

    good luck, i'd say never abandon ship unless they'll be hanging you by the yardarm and document their idiocy and prepare your report for upper management.  But do keep your resume up to date.



  • I cannot believe that the other guys consider such a solution. Do they want to have their entire system of WTF revealed on this site? Avoiding that is enough reason to stick this plan to some place where the sun does not shine.



  • I think your biggest problem with a solution like this is maintainability.  I'm sure the "everything in a db" solution will work, just like any solution will work and may acheive the results you want now.  But when the next guy comes along to make some changes and he now needs to learn all about this ridiculous design, it will take him a long time to figure it all out.  That is why there are frameworks like .net, a common way to do lots of stuff.  Your new design will be just like any framework, there will be a learning curve.  Might as well stick with things that are well known and documented.



  • Yeah this is just plain stupid. A "design nightmare" so to speak. Updating code would now require finding each piece of the enitre page updating several different fields that don't seem relevant to eachother. This is 10X more headache than it's worth. This takes away any hopes of using an IDE to develop the code for the site. Development will come to a standstill. Why? Heres the process...

     Write my code in notepad

    Find where it goes in the DB

    perform an insert of the code

    check the page on the dev site

    find out that this break another module

    find that module

    update its code

    revise previous code if needed

    insert code in db

    rinse, repeat

     Not to mention how to handle special characters ...

    And i doubt that it will be much faster cause it has to first grab the HTML/server side code, then it has to execute it, then it can send it. How many points of failure do you want?

     



  • Ask them for a single case where a solution like this has been implemented successfully.

     



  • <font color="#191970">"In other words, they don't want their system to be affected by new versions of .net anymore."</font>

     So why not get rid of it all together? and do cgi like other have suggested. Your telling that in order to avoid .Net you are going to store .Net code and thats supposed to make it better?  



  • @Jeff S said:

    They really should consider learning ASP.NET.  You write much less code if you know how to use it properly.  Sounds like you've got a bunch of scripters and web designers over there and no one who actually knows how to program. That is actually the biggest drawback with ASP.NET -- only someone who really knows how to program and understands concepts like classes and inheritence and libraries and all that actually ever uses it properly.  Everyone else just treats it like a big bunch of ASP pages and include files.

     

    I would like to think that his team could learn .NET, but if they have managed to get this far in the design process without realizing how retarded their idea is there is really no hope. I'd say that if they want to avoid .NET then they should just learn a different web environment like PHP, JSP, Rails, TurboGears, whatever, but they would end up with the same frustrations since they obviously can't be troubled to learn anything.

    My sincere and whole-hearted advice to the original poster: GET OUT! RUN AS FAST AS YOU CAN! NEVER LOOK BACK!



  • @Kev777 said:

     I agree with you on this.   But their argument is that they are sick of dlls, aspx files, and vb files.    They want as few of those as possible.  The fewer lines of code the better.   They argue that using the .net controls actually creates more code then simply writing a basic html based form.   

     anyway.  debuging this shit is like going back to notepad days of classic asp.   That is why I'm already considering the ak47 over a 22. 

    I hate to repeat myself, but here we go: if they don't want to use .NET then why would they still use .NET in any way, shape, or form? There are plenty of other frameworks and APIs out there that [i]work[/i], not necessarily better than or worse than .NET... but they work. Intelligent people examine their choices when faced with a decision, instead of just burying their heads in the sand. Is there some sort of mandate from way high up that .NET has to be a part of this project at some arbitraty point just because?



  • [quote user="Kev777"]

    "It won't be all that hard to maintain html code because they can continue to use vs, dream, or even front page and use the vb interface to upload the template to the database.  This will make it easy for the web designers (who don't know .net) to integrate their designs"

    [/quote]

    In other words, allowing the least-capable people to completely bypass all forms of testing, QA, and version control before making their changes "live". Brillant!

     [quote user="Kev777"]

    "the page logic is simple.  Just parse this template and stuff that into the website wrapper (header and footer) template. "

    [/quote]

    This argument ended at the word "parse".

    [quote user="Kev777"]

    "this is exactly what sql report services is doing."

    [/quote]

    So go create some SQL reports if that's what they like doing.

    [quote user="Kev777"]

     "We are fed up with having to deploy and roll back dlls or fix problems late at night on production on spot "

    [/quote]

    In other words, they're fed up with trying to be mature professionals who follow appropriate processes and procedures. And why are there no staging environments to roll back to if this is such a constant problem?

    [quote user="Kev777"]

    "the more layers you have the more you have to maintain. "

    [/quote]

    It's called encapsulation and isolation, and it's a GOOD thing. It allows you to monkey around with one section of an application with little or no fear of unintended consequences in another. But that would require mature professionals to create such a cleanly layered application, and you clearly seem to be lacking same at your company.

    [quote user="Kev777"]

     "in five years we don't want to have every version of visual studio installed on our machines just to support all our web applications."

    [/quote]

    <sarcasm>Thankfully SQL server is never updated.</sarcasm> It would be quicker and easier to upgrade from 1.x to 2.0 than to allow this meltdown to occur. Unless you've done some really obtuse things in 1.x (which I'm not discounting after reading what they're doing now) the upgrade from 1.x to 2.0 is nearly seemless.

    [quote user="Kev777"]

    "we will code this in a very clean and efficent manner so that it will be easy to maintain"    

    [/quote]

     So they're not competent enough to create and maintain any kind of proper process for application development, but they're going to be capable of keeping a complete pile of junk "clean" and "easy to maintain"? Laughable.

     

    You should start looking to transfer - either to another team within your company or to another company altogether. This kind of brain-melt is precisely why we won't interview candidates until they've submitted sample code that they've written. Weeds out a lot of these ignorant buffoons long before they start wasting our time with interviews.
     



  • EJECT! EJECT! EJECT!

    [quote user="Kev777"]

    "we will code this in a very clean and efficent manner so that it will be easy to maintain"    

    [/quote]

    Famous last words..

    This design-proposal is crap:

    • It doesn't scale.
    • Migration will be a nightmare. (And yes, the need or at least the wish will arise someday)
    • There is no possibility for revision history (This is necessary. Ask any developer). 

    The last point should be more than reason enough.

    Get out as fast as possible. Start running now and never look back. 



  • ok here is an update.

    The QA people are very happy now because they won't have to worry about installing packages on the web server via Zip files. No more release notes for them to read and procedures for them to f-up.. All they will have to do is test and if there is a problem unattach the new database and attach the old database .

    The  graphic designers are also happy with this solution becuasae they don't understand how to program.  They only know markup and photoshop.  They can just work with the templates, css, and images.    No need to worry if it is php, asp. etc.  they can just work on the html directly.  They can just use the quick and dirty vb.net program to upload and download templates from the database.   

    You know what the sad thing is.   They have already started the coding of the default.aspx page. (which will be the only page required).     This page calls the stored procedure using a select case statement.    It also captures all form data posted to it and calls various update and insert procedures.      There are already a number of security issues with this page.   Form values are required to have the same name as the stored procedure parameter.   And the form name must be the same as the stored procedure name.   What a F-CK up!

    Maybe I can convince these guys to just build a template engine in vs.net or something.  I mean isn't that the right way to go in this case?   Anyway.  I think they will just say that they don't want to write many different versions of that engine (php, asp, .net, etc).

    SQL Server is not a f-ucken web engine.   

     

     

     

     

     

     

     

     




  • I don't know which internet arconym to use .. omg, wtf, lol, rotflmao, they all seem to fall short.

     

     

     



  • [quote user="Kev777"]

    ok here is an update.........

    [/quote]

    So... how's the job search going? 



  • Just an update.

    I took all your advice and quit that shit hole.  I even quit dispite the fact that the boss offered me a completetion bonus of $5000.     

    When they started to create xml files to store session data and use a sql job to clear them from the file system I had enough.

    I'm now working in another company with  a completly new pile of shit. I'll have to detail it sometime.

     

     



  • Actually the new Sharepoint 2007 platform is done in this exact way, everything is in a SQL database, and we as developers create "Web Parts" that are used for the content areas of the site . This is a great platform for a CMS System, the developers create the Web Parts for the users (of course adding properties, methods and events you want visible to the users), they plug them in and voila, a CMS System.

     At the organization I work for we're in the process of moving all our websites to this platform, the us developers simply create the Web Parts so we can hand the whole site off to the Marketing Department and they can add/update/remove content as they see fit, without even knowing the first thing about writing code. Doing it this way it offers them a "Plug & Play" setup for the organizations websites.

    Believe it or not the Sharepoint 2007 Platform is much faster than standard website platforms, having our SQL Server perform all the rendering dramatically speeds up the website performance.

     

    http://office.microsoft.com/en-us/sharepointserver/FX100492001033.aspx
     


Log in to reply