August 4, 2009 at 9:10 pm
And the arguments against using a set of GET* and PUT* SP's to implement any data handling system are?
Peter Edmunds ex-Geek
August 4, 2009 at 9:35 pm
Heh... still on a roll, Steve. Keep it going. I am, however, glad you changed your shirt from the last time.
I can't get over how many people are talking about sp's like they're new or something. 🙂 I've been a long time advocate of using stored procedures as part of the "interface" for a long time. And I'm not talking about the flat stuff that Hibernate and NHibernate make.
So far as plug-in's go... good idea and that's about time, as well. However, I still like source code... a lot.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 5, 2009 at 6:57 am
As this conversation seems to be a load of people, (me included), agreeing with the use of stored procs, etc., to build a layer between applications and the DB, I'd like to point out that sometimes us developers *need* the source code so we can tweak the system to do what we wanted.
In fact, there's a few cases in which I wouldn't mind having access to it as the company didn't bother thinking about stuff that most people would want to do. *cough* Microsoft *cough*.
However, you can over-develop software, (I'd admit to being guilty on that, though most cases I ended up being vindicated), and there are a few situations where software is just too complex that it's hard to navigate the help and find everything you want to do. Or is that a fault of the documentation...?
PS: Could someone, please, explain why the spell check option refuses to recognise almost any word I've typed in this reply. Pretty please.
Perhaps your language setting is incorrect?[/quote]
I can't find any obvious language setting on the site, and my PC's language is set to UK, although even an Anglophile like me knows that we share those words with the American language... Perhaps Steve can offer some explanation?
August 5, 2009 at 8:05 am
I'll have to check on the spell check feature.
August 5, 2009 at 9:10 am
Paul (8/5/2009)
... and there are a few situations where software is just too complex that it's hard to navigate the help and find everything you want to do. Or is that a fault of the documentation...?
Just an opinion, but I'd have to say that comes from too many hands in the pot that don't know the simple way of doing things and, possibly, no central "vision" for how things should work. For example, does anyone but me still use a "Master System Flow Chart" in an Alice's Restaurant fashion? I'm thinking probably not... so, what you frequently end up with is similar objects, long chains of inheritence, similar functions, and a whole bunch of code made up on the fly. And, yeap, it's all the fault of documentation (the lack of it, actually) and someone to enforce the master plan.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 5, 2009 at 2:13 pm
You can get anything you want at the Master System Flow Chart.
Couldn't agree with you more Jeff.
Peter Edmunds ex-Geek
August 20, 2009 at 8:46 am
Jeff Moden (8/5/2009)
Just an opinion, but I'd have to say that comes from too many hands in the pot that don't know the simple way of doing things and, possibly, no central "vision" for how things should work. For example, does anyone but me still use a "Master System Flow Chart" in an Alice's Restaurant fashion? I'm thinking probably not... so, what you frequently end up with is similar objects, long chains of inheritence, similar functions, and a whole bunch of code made up on the fly. And, yeap, it's all the fault of documentation (the lack of it, actually) and someone to enforce the master plan.
I must confess not have heard of this "Master System Flow Chart" before, (any one care to explain?), but I've come upon a number of systems that were started by someone else with no actual plan, and I ended up being forced to re-design huge chunks of the code, (being a programmer!), because they hadn't realised some aspect to the application or the language they were developing in.
Although I try to push for as much documentation as possible, and religiously comment the code, I'm not always successful in getting probably the most important type of documentation; requirements capture. I'd expect this would apply to DBAs as well though, as I've never properly been one, (come close once, mainly because there was no-one else to do it), it might not entirely fit in with that side of things.
Paul
PS: On the upside, the spell-check's OK now, except that it doesn't understand "DBAs". 😉
October 26, 2009 at 5:40 am
Jeff Moden (8/4/2009)
I can't get over how many people are talking about sp's like they're new or something. 🙂 I've been a long time advocate of using stored procedures as part of the "interface" for a long time.
I'll go with Jeff here. I've tried to operate a rule where the application sees only stored procedures, read-only views, and maybe some functions - it's not allowed to know what tables exist or what columns are in which table because if it does know that it will create dependencies and all modularity is out of the window. In the last thing I worked on the app wasn't even allowed to know which data was in which database (data was split between databases to allow separate maintenance policies for different classes of data, to separate customer-specific data from generic data, to separate data that could be updated on customer-sites from data that could only be updated back at the ranch (ie was read-only on customer sites) and for other operational convenience issues.
I tend to put quite a lot of what some think of as application functionality behind that API too - various types of business logic are so tightly connected with the data that it would be crazy to take them out of the datbase (of course it can be equally crazy to put too much of the app into the db). I've been advocating this approach for a very long time, and trying to enforce it (with different degrees of success with different development teams) for nearly as long. There are advantages other than the obvious ones to do with modularity: for example security can be set up so that the only access permissions on data are those inherited from stored procedures (and triggers, where needed -should be pretty infrequent) and from read-only views (views with empty instead of triggers for insert, update, and delete).
One thing that no-one has mentioned is that the API should of course make things like email delivery asynchronous (ie not occur in processes holding DB locks other than schema stability) and ideally each SP call should be transaction-oriented (execute one or more complete transactions, and not return with a transaction still open) so that the application can't hold DB locks while asking for user input - but that ideal may not always be possible (because it may put too much of the application logic inside the database, and we don't want to be writing things in SQL that would be better written in JScript or C#, but more importantly because insisting on it can render the delivery of certain GUI requirements completely impossible) and in cases where we can't have this ideal (fortunately they are rare) there will need to be strict rules about what the app can do.
I also like to have another API (actually two more layers) a bit higher up, to conceal all the mess of the ODBC or ADO interfaces, add things like enumerations (because although these could - and should - be enforceded in SQL using check constraints and/or parameter validation, MS SQL user defined types are a nasty trap that one should avoid falling into), and present an application-oriented interface. This should present the application developer with a set of classes (if the application work is done in an OO language, or even in a poor imitation of OO like C++) or instantiations of existential types as modules (my preferred approach, but who programmes in a language with a decent type system, any more?), or whatever is appropriate for the development environment(s) to be supported. One of the useful things about this level is that it takes away a lot of the pain of MS updates that change the world (for example the string of updates a few years back which gradually began to enforce the rules about cursor location and cursor types for ADO operations returning multiple potentially incompletely consumed record sets - that could have put us out of business or forced us to delay applying MS updates on customer sites if it had affected too much, but with modular design it affected very little and was trivial to fix); it also makes big upgrades - going from ADO to ADO.net, for example - very much easier.
Tom
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply