Heya Taco, So do you script everything and do nothing using the GUI?
Have you ever tried building the first version of your database in Enterprise Manager, then exporting the SQL script and making minor adjustments to it there? I'm really interested in getting the DB to do more work for me, but am just wondering about the best way to approach it... Currently I use the database for very little except storing the data... all the logic and validity checking is done in the application. I know should be using it for more, which is why I'm learning more about it now. Its interesting when you talk to people who manage databases for big companies... for them, the database is the where every single bit of processing takes place, and any applications that access the DB are extremely thin. In a way that can make your development more portable, I mean list all the major enterprise RDBMS's out there.. I can think of MS-SQL, Oracle, Postgres, Informix, probably a few more... now think of all the ways you could be asked by a client to access that data: Cold Fusion, ASP, ASP.NET, PHP, Perl, MS Access front end, Flash, etc..., you get the idea? From what I can tell there are far more choices at the Presentation Logic tier than at the Data Access tier.. talking in a rough approximation of the N-tier application architecture. Wouldn't it make more sense to do all the gutsy processing at the level that is less likely to change? Also, if you develop your database using ANSI standards, it should translate pretty well between vendors... Feel free to shoot my argument down in flames anyone, its quite an interesting topic... bye! On Wed, 2004-03-17 at 20:41, Taco Fleur wrote: > I don't agree with them. > > How often have you seen a company switch database vendors? > > Documentation and commenting of the code is the same as with programming in > CF. > > Maintenance is no nightmare when you work with stored procedures. > Don't forget all the Stored Procedures, triggers and what not can be stored > as SQL files, at least that's how I do most of my SQL development, i.e. open > Query Analyzer open the file make any modifications execute the sql file, > save it and close it. > > Taco Fleur > Tell me and I will forget > Show me and I will remember > Teach me and I will learn > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Brett Payne-Rhodes > > Sent: Wednesday, 17 March 2004 6:57 PM > > To: CFAussie Mailing List > > Subject: [cfaussie] Re: Database programming > > > > > > Hi Ryan, > > > > Call me a dinosaur but I would never do this. > > > > You are locked in to your database vendor for life. > > > > Maintenance is a nightmare. > > > > How do you document such a system, knowing that documentation > > is never > > up to date? At least with code you can find out what is going > > on. With a > > system where the business logic is buried in the database you wind up > > delving through triggers and stored procedures and > > constraints with few > > if any obvious connections between them. > > > > Not to mention that 'database' programmers will probably cost > > significantly more than a CF programmer. > > > > You asked for thoughts. These are mine. Nobody has to agree > > with them... > > > > Brett > > B) > > > > Ryan Sabir wrote: > > > 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 > > > > > > > > > -- > > Brett Payne-Rhodes > > Eaglehawk Computing > > t: +61 (0)8 9371-0471 > > f: +61 (0)8 9371-0470 > > m: +61 (0)414 371 047 > > e: [EMAIL PROTECTED] > > w: www.ehc.net.au > > > > > > --- > > 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 > > > > > --- > 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 > --- 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
