I agree with you that SP aren't always required. But I must address some of our statements:
Every element of a database can be properly versioned. Each table, view, sp, etc. has a DDL query that creates it. For instance, I use CaseStudio to model my databases, the "output" script of my model is always properly versioned (it's a text document).
The name you use for a store procedure generally doesn't matter. That is what documentation is for!
If you don't need to have some/all of your bussiness logic in stored procedures, then I don't see why creating them on-the-fly is an improvement. It's far faster and reasonable to use standard DML SQL queries using prepared statements.
I agree with you in that not every operation over a database should be done with stored procedures. Stored procedures should be used where there is complex or sensitive bussiness logic behind. Other cases should be addressed using referential integrity, triggers, views, and proper user permissions assignment.
Actually you can do what you say rather easily, although it makes no sense at all. All you need is enough priviledges for creation, execution and deletion of stored procedures. But I really don't see any benefit in "creating" a store procedure on-the-fly.
1. In your app issue a DDL query, like CREATE PROCEDURE....
2. In your app call your recently created stored procedure
3. In your app drop the procedure DROP PROCEDURE...
Store procedures and triggers are an architectural tool! It's a way to isolate your bussiness logic. Think of it as a way a company publishes an API to access and manipulate their information.
At my previous job we designed, developed and deployed huge database centric solutions in Oracle running on... Windows 2000. Let me note that without a glitch.
Oracle is a big, complex, powerful beast. In case of troubles you certainly need a qualified DBA.
I was think about an all-MS shop that was required to submit some docs in opendoc format. Perhaps they just bought tons of MsOffice licences and can't replace them with openoffice (what will shareholders say!), or maybe they have tight dependencies on other Ms technologies.
Not always OpenOffice loads.doc/.xls files correctly. Perhaps a macro run within Office can access correcltly formatting information (at least the info that is relevant for OpenDoc format).
I'm no MS Office expert, but couldn't a knowledgeable developer create a macro/vbscript that exports an MsOffice document into OpenDoc format?
To make the full roundtrip, Open Office alredy exports to MsOffice propietary formats.
Don't you just love scriptable environments:D
Actually you can do what you say rather easily, although it makes no sense at all. All you need is enough priviledges for creation, execution and deletion of stored procedures. But I really don't see any benefit in "creating" a store procedure on-the-fly.
.... ...
1. In your app issue a DDL query, like CREATE PROCEDURE
2. In your app call your recently created stored procedure
3. In your app drop the procedure DROP PROCEDURE
Store procedures and triggers are an architectural tool! It's a way to isolate your bussiness logic. Think of it as a way a company publishes an API to access and manipulate their information.
Because the only way to notice the difference between GMail and G-Mail is to see them written.
Not everything is written, humans have a HUGE oral tradition.
Disclaimer: I'm not a native English speaker, but my understanding is that GMail and G-Mail are pronounced the same.
At my previous job we designed, developed and deployed huge database centric solutions in Oracle running on... Windows 2000. Let me note that without a glitch.
Oracle is a big, complex, powerful beast. In case of troubles you certainly need a qualified DBA.
No pain, no gain.
In fact BIOS stands for Basic Input Output System. It is supposed to be able to access your Input/Output devices like... er... hard disks!
The real problem is that bioses perform raw I/O, they have no concept of filesystems: is that an EXT2 filesystem? perhaps it's an NTFS?
That's for sure!
.doc/.xls files correctly. Perhaps a macro run within Office can access correcltly formatting information (at least the info that is relevant for OpenDoc format).
I was think about an all-MS shop that was required to submit some docs in opendoc format. Perhaps they just bought tons of MsOffice licences and can't replace them with openoffice (what will shareholders say!), or maybe they have tight dependencies on other Ms technologies.
Not always OpenOffice loads
I'm no MS Office expert, but couldn't a knowledgeable developer create a macro/vbscript that exports an MsOffice document into OpenDoc format? :D
To make the full roundtrip, Open Office alredy exports to MsOffice propietary formats.
Don't you just love scriptable environments