Hi Ryan, Juust some thoughts (primarily MSSQL perspective)
Constraints (PK,FK,Unique), NULL/NOT NULL, Defaults, correct Datatypes (rather than always using varchars) etc are invaluable to data integrity and I almost always implement because it costs nothing. I love storedprocedures I wish they supported arrays as input parameters! Though 2000 supports xml which can be parsed inside the sproc! You can return multiple recordsets when required which is a real performance boost too. They can be encypted too, and they are harder to decrypt than cf templates so your logic/property is more protected. I love views too because you can change the schema without breaking your queries! I think UDF's (200) are awesome because you can do a select on their return value (if its of type table) I don't like triggers (though I use them, but not as much as sprocs) mainly cause you forget they are there and then they mess with you! They arn't needed if you control CRUD through sprocs. I use scripts to write the CRUD spocs and to write the cf call to the sproc so there goes that excuse for not using them.. One of the major reasons for putting certain logic in the db is so that your asp page or vb client or cfm page or wscript all enjoy the logic in the db layer. At minimum no (invalid) crap gets in there! So you have to be realistic about whether any other apps are going to interact with the database. With webservices it is probably more likely that those other apps could route through the cf app thus maintaing that single entry point. In my experience companies don't change databases very often. It is all about perspective (and religion) though If I wrote a CMS to sell I'd put all the logic in the application (so i didn't limit my selling optunities) If I wasn't strong on DBs I'd put all the logic in the application But if I was building a custom enterprise application I would definately try take advantage of all that the db level supported. It is definetly more work when you have to work with script changes to the db objects and they don't integrate easily/nicely withh source control either. Now of course if I was working with oracle...everything would be in the application layer :). Though this says more about me than oracle. Elliot "Ryan Sabir" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hey all, > > Been doing some pretty intense study of MS-SQL server lately and a few > questions came up... > > Basically, a lot of software developers say to put all your business > logic into the database, and to support it by constraints at the > database level, instead of at the application (i.e. CF) level. This > means things like using triggers to update multiple rows in the > database, and having checks on the validity of foreign keys etc... > > The more I look at this, the more they seem to be saying to build your > entire application on the database server.... so my question is how > should Cold Fusion fit into this? > > With the XML capabilities of SQL Server 2000, it would be possible to > write an entire application in the database, and link stylesheets to > the XML output, completely bypassing CF. Has anyone tried anything > like this? > > I imagine this is not a viable method to build a serious application, > I guess because SQL and VB / C# are more cumbersome to work with than > CF.. but then where do you draw the line? How do you decide that a > particular piece of business logic is more suited to be run at the > database level, or at the application level? > > Any thoughts? > > > > ----------------------- > Ryan Sabir > Newgency Pty Ltd > 2a Broughton St > Paddington 2021 > Sydney, Australia > Ph (02) 9331 2133 > Fax (02) 9331 5199 > Mobile: 0411 512 454 > http://www.newgency.com/index.cfm?referer=rysig > > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
