Slashdot Mirror
Where Does the Business Logic Belong?
logic-Dilemma queries: "I'm currently working in a big project that involves creating tons of reports. These reports require extensively data operation and manipulation in order to be build, and most of that can be handled directly by the DBMS (which would greatly increase performance and implementation time). However, letting all business logic sit in the database implies that we will be extremely attached to one vendor, which kills any attempt at portability. What would you do to tackle this dilemma? Have you ever faced a situation in which the choice between clean design/portability versus performance would change dramatically the whole system design? What have you chosen?"
Quite simply.
...
Procedural sql is reasonably portable. I don't know about other RDBMs, but postgres supports perl, tcl, and others. That portable enough for ya?
-73, de n1ywb
www.n1ywb.com
Follow the priority list and go from there.
If the priority is minimize development time, that might tell you one thing, if it is to maximize portability that might suggest another.
For example if you are a pure Oracle shop, have been for 10 years, would never port off of it - why should you care that your logic is implemented inside Oracle. If you are prototyping on a new database, and have no history with it (or any other product) you had better come up with a different answer
I have mod points and I am not afraid to use them
In general, I would put it into the place that is easiest to maintain. I've put it into stored procedures and views in the past. SQL is relatively portable as are stored procedures due to their conciseness.
Definately don't put it into the application.
Eh -
Just last week I was offered a job porting a bunch of business rules written in MS SQL stored procedures to Oracle stored procedures at a nice fat billing rate.
Fight unemployment! Use stored procedures!
What is even better is when they break between releases from the same vendor. Ka-Ching!!
(Bear with me, it's not a troll).
10+ years of experience in the Financial/Banking sector might not tell you much, but it has taught me that business/domain logic changes so frequently so as to make any possibility of portability be remote, in the best case. Stored Procedures just save your life, period. Also, and perhaps more relevantly, your client probably has made a substantial investment on the RDBMS, and they won't even dream of switching DB layers down the line.
If you're confident about the choice of RDBMS vis-à-vis its architectonic permanence (Is the client happy with it? Are you sure it's gonna sustain the load you plan?), you shouldn't worry about portability in, say, mid-termish 3 years after installation. However, if what you want is to re-sell (that is, productize) the code to another potential client who might have a different RDBMS, your design goals should be adjusted accordingly (for instance, you can insist on portability, by building a middle-tier; or you can push for a RDBMS you know you can pitch together with your system to whomever you want to sell it afterwards).
Is this an internal app? Is it going to sit on an Oracle or DB2 box forever? Then toss the business logic in the database if it can be done more efficiently that way.
.NET or PHP. People spend more money migrating their data than they ever do migrating their code. If you put the code next to the data on the database, your likely to get yourself a high performance app that will provide you support contracts till the end of days.
.NET and MS tech.
If you're going to try to market this as a product, then concentrate on devleoping the business logic, after all, that's what businesses want to buy. They'll pay you to port it to their database or just buy a copy of the database you've written it for, if it's valuable enough to them.
I've been working on apps like this for years. Just stick it in the database. It's so much easier than maintaining a bunch of query engine code or mappings so you can keep your precious business logic in a "programming language". If your using Oracle, you could just write it in Java and install it on the database. PL/SQL or whatever you're writing the business logic in will probably be around longer than any app language like
All that being said, this approach works best if you're using a database that has support for stored procedures, embedded code and custom types, either one of the commercial biggies (Oracle, DB2) or PostgreSQL. Firebird (or whatever they're calling it this week) might work too. I wouldn't trust MySQL for this type of work yet though, I don't think it supports code in the database all that well yet.
Personally, I think databases are going to wind up absorbing application servers like J2EE containers and will eventually look like a relational/object hybrid with interfaces to various protocols and container environments. After all, those engines are pretty simple to slap on top of a good database. Oracle and IBM are already moving in this direction somewhat. Oracle more than IBM. I think MS is going to move this way with SQL Server as well, but of course it will only be for
Does that help?
Arrogance is Confidence which lacks integrity. -- me
Couple of things. First off, if you're a publicly traded company go score points with your managers by suggesting that you should talk to the Risk Management and Comp Sec guys at your accounting firm. They'll give you criteria that the project should meet (usually very low impact to implement early but nightmarish to implement later) if you want the data to meet financial disclosure and Sorbains Oxley (SOX) criteria. If you're publicly traded and you don't meet SOX criteria at (or by) the end of this fiscal year then you stand to pay HUGE fines and possibly get de-listed. (Trust me, not meeting SOX criteria by the end of this year would be BAD.)
Business Intelligence and many widespread corporate reporting tools are often subject to SOX regulations. The Risk Management guys will usually have an opinion about the portability vs performance issue for you. (Also, these guys are way way way too busy this year to artificially create more work for themselves. Every publically traded company in the US is trying to get these guys to sign off before the year end.)
Second, look into some of the XML data portability ideas and solutions out there... I can't name anything off the top of my head, but there are companies out there with enterprise and off the shelf data portability options. Also, if you're a flexible development team you probably have someone who can cobble together something good using XML. Google XML Data Portability and you'll get started on pointers.
If you are concerned about vendor lock in, I would suggest Hibernate as a data persistence layer. It lets you abstract out interactions with your database so that switching over from one vendor to another is a simple matter of changing a configuration file.
Further, Hibernate is battle tested, and used in the real world.
That way different 'vendors' products are similar in features, if not identical. After a few years, most GPL projects cross-seed each other enough to make switching pretty painless. And if you really have to switch before then, you can take your implementation *and* your features with you.
"I assumed blithely that there were no elves out there in the darkness"
I think the best place for business logic is the database server.
The COM middle tier business logic MS was promoting in the 90's was a joke. I found it to just be another layer of abstration with no benifit.
If you place everything in stored procedures you get a very centralized app that any client application can connect to (web, java, etc...)
If you're worried about being locked into one DBMS platform, try to write all your queries and stored procs with standard sql. Avoid database specific features, then future migration is easier.
Remember, when you are running a stored procedure, you are ceding control of your application to the database. It may or may not be appropriate to do this. Often this is an issue that doesn't get enough consideration.
It's simple: I demand prosecution for torture.
>I'm currently working in a big project that involves creating tons of reports
.net, since you are platform dependent.
Ahh, there's your problem right there.
Now, the reports are static, meaning they are standards, run at specific intervals.
Later, though, and much sooner that you expect, the requirements will change to doing a lot of data manipulation on the fly.
If you want to make a truly workable system, design an interface for user-wuery creation, and allow them to save their queries, in custom/personal folders. Also allow them to share their queries with others.
I know, it's a pain, but it gives you extreme flexibility in the long run.
A plus is to allow the reports to be converted to png graphics on the fly, so that they are very hard to modify.
Another plus is that you can standardize the SQL and thus ensure compatibility across multiple data sources.
Watch out: make sure the presentation language is portable itself and has a long run-life. PHP and PERL are best. Python is good, but it's harder to find programmers. Java is poor for that, but serviceable. Also, SUN isn't in the best shape these days, so Java's future is shaky 5+ years from now. You can also use jsp, but same applies.
Go for Apache on the web server. Can't go wrong there. If Java then Tomcat.
Stay clear of asp and
As far as stored procedures, ok, but be really careful: they are hard as hell to debug after a while.
If you must use stored procedures, document the hell out of them , make nice diagrams, and do separate text documentation explaining the reasoning behind each one. (this in fact applie to all code written by your shop. But you knew that.)
Finally, take a look at openoffice and its db access. It might be that what you are trying to do might be feasible with it.
"Piter, too, is dead."
Have you ever faced a situation in which the choice between clean design/portability versus performance would change dramatically the whole system design?
Yes, I have.
What have you chosen?Clean and portable.
Reasonable performance right now when you first write your code is good enough.
More important is to write maintainable (readable and understandable) and extendable code.
We have high performing applications written 10 years ago that sit on the scrap heap that few people know or love these days because they were tuned too tightly to getting performance in a very specific situation. But situations are always changing. Highly optimized applications are too specific and too fragile to be useful very long.
Meanwhile, an originally clean design that was of only adequate performance has been used and used and used. And it's become bloated and creeping with all kinds of ugly useful features simply because people could easily add them on. Once there was a rewrite to improve performance when resources were available because a lot of people were using the code.
Here's the irony: lots of surgical scars on old code is a testament to its successful conception and to its continued usefulness, as well as being a motivation for replacing it with the next generation code, which is what you usually hear about at the watercooler.
"Provided by the management for your protection."
My experience is this works best:
Reports and other visual output generated at the client using simple data structures spit out by a procedure (middle-tier) layer.
Java/Ruby/Perl/Python/C++ (gasp! adjust for efficiency) through XML-RPC or SOAP works well as a middle-tier layer. Export the grunt work of searching and sorting as SQL statements to your database. Give the layer an SQL-pass-through command so you can prototype code in your client easily, then port/move the code into the middle layer.
Do it over HTTP or pipe it through SSH.
The database can be anything, MySQL/Oracle/MS SQL. Don't write any procedures or anything to them. They are not very portable; it's very easy to get blocked in, at least in my experience. I'm sure lots of people are good at not getting blocked in, but it's not automatic.
This is what the fascade pattern is for. I wouldn't worry too much about RDBMS portability. However, putting your SP calls behind some kind of fascade at least gives you portability for the code which will utilize the report data. Let the DBMS do what DBMS's are good at.
reech bee-yond ur clip-0n
the answer depends: is your app a product? if so, it should probably support whatever rdbmses that your potential clients use. if it's a custom app for a client, do they use more than one rdbms? these are the only two cases in which it makes sense to spend substantial effort on isolating your database layer. otherwise, take the stored procedures and run -- this is exactly what they were designed for. there are a couple other advantages (other than performance) which may not have been mentioned:
1) abstraction. yes, abstracting the data layer at the database means accepting that you're tied to that database, which isn't a bad thing: i grew up with oracle and still swear by it. as a result, you only write one db layer api, not one per supported dbms per target business logic language.
2) depending on which rdbms and how you set up the user access, you can also probably push a large chunk of the connection pooling onto the db engine rather than having to manage it yourself.
3) access control. microsoft mentioned this several times at their devdays convention. i was surprised that it was news to them (hint: fewer doors means fewer ways in). regardless, it's a good idea: i've always seen allowing execution of arbitrary sql statements by joe random as an invitation for bad things.
4) one place to go to for developer support requests.
hope this helps.
After 20+ years of wroking with DBMSes, including 10+ as a DBA, I can tell you that you want your business logic in the DBMS - EVERY TIME YOU POSSIBLY CAN DO IT. This is especially true of RI in the DBMS.
If you think that application developers are going to implement the business logic in the application, you better think again. I have watched many systems over the years, and NOT ONCE has the application group implemented the business logic in the application and gotten it right.
In one shop (RI not available in the DBMS, thank you to THAT vendor) we had 1 guy whose job it was to fix data errors. I tracked usage, and he was responsible for 1/3 of the resources used day in and day out just fixing errors in the data every day.
The best place for buiness logic in in Access Macros!!! It's even better when you have access link to Excell tables for it's data!!!!
Don't use Access Visual Basic - clippy will come down hard on you!!!! Macros are where it's at!!! Marcos are even unicode compliant - so localisation is really EZ!!!!!
DONT USE ACCESS 2000/XP/2003 - it's buggy!!! Aceess 2.0 or 97 is where all the stable apps are!!!!
WORD 97 has great macro support too - don't be afraid to put some business logice there.
There's a rounding bug in Access that you can use to get more money out of your customers!!!! It inflates the sales tax - keep the change!!! You deserve it!!!!
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
I'd never use a database for anything more than storing data and doing simple fast queries to get it out. You are usually tied to one big database machine/cluster and it is the most expensive to scale. So more logic you put into the DB the more you will pay if you need to scale it (not to mention all the expensive DBA you will need to hire to manage the stored procedures, et al).
Fetch the data into business objects of some sort (or a local data store), work the data as you need then send it up to the presentation layer and you should have a nice architecture that can scale quite easily.
If you are doing reports, load data from DB into a map/map, process it, then generate XML data from the map/map and use XSLT to transform it to whatever output you like. Quite efficient and easily scaled.
If you create a library or set of libraries that have the interface to the queries/reports, then you can implement the reports in the database for speed, and if you ever want to change vendors you just change the code in the library. This way the rest of your application stays the same. Portability is achieved with smallish work, and you can get all the speed bootst you want from the RDBMS without commiting to it for eternity.
It's hard to give a more precise answer without knowing the details of your architecture.
But, in general, I prefer to partition an app that requires extensive business logic into separate logical layers (whether or not these are separate physical layers).
Database-side stored procedures do limit portability, but if you can run similar code at a point in your application that is physically close to the DB server, or at least on the same fast network segment, this gives you better performance than you'd get having the logic in your front-end, with less portability hassles than if you'd coded them in your RDBMS's proprietary stored procedure language.
This is only a slight variation on the MVC (model/view/controller) pattern first popularized by Smalltalk decades ago. It worked nicely then, and is even better now, because both hardware and networks are a lot more powerful.
Nonaggression works!
Don't create stored procedure unles you are wiling to sit with one vendor for the rest of your life (bad option).
:).
Store "standard" (avoid trendy or new fuctions, data arrangement can be done with your own software procedures) sql statements in your business logic or data files (your choice).
Create an abstract class to access your database something you can rewrite for any vendor.
Comment your queries, after 6 month a long query can be a pain in the ass to debug or alter.
Keep it simple use various simple queries and use the power of unions and intercts instead of a looooog query.
Cache your commonly used results and parse/process them as much as possible (don't rely on your network or database availability), knock yourself out with XML if you want.
Store storicals on disk to have a fail safe for your database.
Keep those connections to your database low/few/simple.
Need more consulting let me know
portability is a great thing, but only if the app is meant to be distributed. if it's meant to be in-house save yourself the headache and do it all in PL/SQL. the app will be simpler and it'll perform better. the odds that your employer will switch platforms are, realistically, very low. besides, it's likely that speed of development and speed of execution are management's top priorities for the project. and even if they do, then you get to rewrite the app, which gives you a chance to clean it up down the road and provides you with plenty of work.
Personally, I think databases are going to wind up absorbing application servers like J2EE containers and will eventually look like a relational/object hybrid with interfaces to various protocols and container environments.
Does anyone have any experience with Microsoft's new ObjectSpaces persistent object initiative for .NET? Some overview here:
The ["scientific"] data we're generating is very large, and much more binary/object-ish than ASCII/SQL/RDBM-ish in nature.CA/Fujitsu abandoned their Jasmine OO database product, and it looks like Progress is allowing ObjectStore to wither on the vine.
Oh, AND WE NEED 64-BIT DATABASES AND 64-BIT PROGRAMMING LANGUAGES LIKE YESTERDAY!!! SQL's 32-bit BLOB just doesn't cut the mustard. Hell, the following won't even compile on Java 1.5:
}Applications that have used all the facilities of the database GENERALLY take less time and have fewer bugs.
Typically we could have rewritten the entire application for a different platform in equal or less time than trying to maintain platform or DB independance. As well I have NEVER seen a project designed to be independant actually take advantage of that and move to a different platform, NEVER.
Business logic is *IMPORTANT*. Therefore, it should be replicated in as many places as possible. Anything that touches the database should have a separate copy of the same logic in it. A handy way to achieve this state, which functions both as a distributed versioning system and a set of backups which is both effective and affective, is, when writing some new code, to find some old code sitting around that does more or less what you want and use the "cut and paste" feature of your editor.
You'll find it most useful to have as many subtle mutations of the same piece of code around and in production use as possible -- this way, when you need to use one, something that does exactly what you need will be right at hand. Also, that contributes to a healthy "immune system" for your server.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
In general, using OLAP will be 10x faster than using stored procedures. If you really need real-time reporting that happens to use 10's of milions of rows of data, use Oracle, or Sybase. Microsoft's Analysis Service works well for small-ish database with less than 2 million rows for real-time stuff. If you don't need real-time reporting, then Analysis service will probably be sufficient in MOLAP mode. EssBase also should fit the bill if you don't need real-time reporting on large 10million+ datasets.
Other good reasons for externalizing the business logic is if a significant part of the data is external to the database. In that case, you may want to calculate what you can in the database and store it in a table, then use those calculated values with the external data to get the final values.
Tablizer has an entire OOP-is-mad Web site, and I could never figure out what he was talking about because I do a lot of GUI work where OO is as essential as air (although Tablizer thinks there could be some kind of table-driven GUI, but I think that is reinventing OO in the style of C-level Gnome programming).
I believe the point is that in certain domains, OO is the hammer that thinks every pointy thing sticking up is a nail.
The first question to ask yourself when deciding where to put something is where did it come from? Often, this is the best place to put it.
I have been part of the whole where-does-the-business-logic-belong process many times, and if your company is anything like the ones I've seen, some middle manager with training in a field unrelated to anything you're dealing with pulled the "business logic" out of someplace, and you might suggest that they stuff it back in the same place when they are finished with it.
In any case, bright light often is bad for business logic, so it should be kept someplace like that anyway.
-- MarkusQ
Good design usually means slightly more initial coding work, and insanely less maintenance. I learned this from this book, particularly this chapter. Admittedly, they are porting to Windows. They are also using C++, which I thoroughly despise. They have also designed their code so well that it only takes one section -- while we're learning new gui concepts -- to port a commandline program to a Windows GUI.
I admit that developing for something portable to begin with (java, parrot, wxwindows, gtk+, or whatever the solution is for databases) can save you the trouble of porting it yourself -- someone ported the library for you -- but still, code can be made modular enough that you can have a port done by the time the meeting on deciding whether to port is over. (Assuming they let you hack on a laptop during said meeting.)
Bottom line -- worry about modularity and general flexibility before you worry about portability, and in the unlikely even that you have to port, it's not a big deal.
Don't thank God, thank a doctor!
On the client, of course!
According to the CFO, it belongs in India. See you in the unemployment line.
Show me on the doll where his noodly appendage touched you.
Or you could do an Abstract Factory Pattern and have a configurable database layer for multiple database implementations.
Relational database theory in no way prevents you from having any types you like in the database (current maintainers of the academic theory would point out that "object/relational" databases are just relational databases working the way they should.)
Except for one thing: SQL [like Java] is a 32-bit language!!!
SQL BLOBs are 32-bit entities!
Java arrays are 32-bit entities!
WE NEED 64-BIT DATA TYPES AND 64-BIT PROGRAMMING LANGUAGES!!!
The best solution, also with respect to scalability, is to implement an application server, which might run on the same machine for that matter as the database server. Go for a three-tier solution. Implementing business logic at the client is a bad idea. Implementing it as stored procedures is a less good idea.
There is no logic in business. It's all about who you smile at, who you lie to, who you steal from, who you do favours for, who you do special favours for, who you fuck, who fucks you, who you back stab, who you kick when they're down and who you offer a helping hand up only to get a blow job later.
look at Ralf Kimballs books on DW design.
The reporting logic can be held using multi-dimensional tables in OLAP cubes or similar so the reports then 'pop put' very quickly.
The hard bit is organising the data properly and getting the SQL tuned for the ETL phase.
You didn't say enough about your requirements to be able to say for sure, but here are some points that may help you:
I tend to do things using application servers, but this is because I have to combine data from different sources, not all of them databases. It makes sense to have the business logic all in one place - including user rights, audit trail/logging etc. I also like the fact that users don't have direct access to the database.
The right answer for you depends more on your requirements than anything else. There is no answer which is always right for all situations.
-- Steve
I'd choose a very high level design tool which automatically generates the required programs and normalize database schema for .NET, Java and several other platforms. You get automatic maintenance, automatic portability across platforms and DBMS vendors and much more. See their website
One of the things to realize about reporting is that the type of queries made to a database for reports is very different from the queries made during use of the application.
A solution to your performance problem probably lies in creating some views into your database that represent the data in a less transactional way - create the views such that they are not normalized for transactions but rather for the queries you expect, and the report generation speed problems will take care of itself, and you can leave the business logic code portable.
For example, somebody might want a report like "sales by state", and this report takes age to run against your transactional database because it's normalized for inserting a sale across many tables, and a select to retrieve this data might take a bunch of joins across all tables. If you create views, or replicate the data to another database with a different scheme, your select might be "select * from sales where state=''" and return very quickly.
The advantage to this approach is that you can create business logic that spans multiple resources (RDBMS, FTP/HTTP, filesystems, etc) and multiple apps (SWT/swing/applet, web/JSP/ASP, .NET systems, etc). Need a .NET app to use a Java business object created from specially-formatted data returned by a credit card clearinghouse over an SSL connection on a non-standard port? No problem! The disadvantage is that there's quite a bit of coding overhead involved, and you have to be careful. We decided against using EJBs, and just built our own framework.
You don't want to put business logic in a database if it involves sending a shipping manifest to the post office via their FTP servers, or to authorize a credit card. You don't want it in the app, either, since you may want different apps to have that capability. In particular, you want the capability both from your web site, and from (say) internal VB.NET apps used in accounting. The solution is to use an n-tiered approach.
P.S. Yes, we run a heterogeneous environment. For good reason. Some user-facing apps are faster written and more efficient in other languages. Some apps have been outsourced to companies that, following our communication and networking specs, turned out VB or VC++ code. This is a fact of business life, and not subject to negotiation or discussion, so flames will be routed to /dev/null. Also, databases are for storing data, not for being used as an application platform. If you want an app platform, use one. There are plenty out there. Databases should store and retrieve my data quickly, and not be distracted by image formats and gopher protocols. That's what real languages are for. [/Oracle DBMS_KITCHEN_SINK dig]
P.P.S. All of the above may not apply to you if you're not a big enough shop, or if you have different needs. YMMV.
Reports are usually the "ugly" part of a system precisely because performance is usually extremely important, which leads the developer to break some design rules or duplicate code that is already in the app, putting it in stored procedures so that the reports run faster.
However, once you get to the reports, the system is usually at a stable stage as far as business rules are concerned, so they won't change much (if at all).
Finally, that whole thing about migrating from one database to another, well... it just doesn't happen that often and when it does, it will take time and patience and a lot of testing, no matter how well you built your application, and like some other poster said (jokingly) before, you will be giving someone a job when it's time to change DBMS.
Go hug some trees.
Our project recently switched from PHP4 to Mono ASPX. Its a business management software solution. We made made the change from PHP4 to Mono because ASPX almost demands that you abstract your business logic away from your HTML. All of the business logic goes into a DLL file instead of being embedded in HTML. (This helps if you want to use the same functionality in a different Mono project)
and two-level, even. Every object has an associated user as well as a database. If you just look for database.object, it looks for database.yourlogin.object, and if that isn't there it uses database.dbo.object. For that matter, you can also just qualify it outright.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
Putting business logic in the database may be faster for a single client, but what happens as you get lots of client? I would think it would be easier to cluster the application server as opposed to the database server, so put the busines logic there.
It depends.
There are many ways to query
You can use embedded-SQL, stored procedures, or perhaps (if you're careful|lucky) pull off similar performance from a prepared statement.
In many cases, the real overhead isn't the query, but merely passing the large amounts of data from the db to the app server. It depends.
THE issue with web based applications**
I run into the portability vs. speed issue all the time. It's THE fundamental issue with web-based architectures. OO Design on a large-scale, web-based system can be tough. If you want to build a solid but simple web based application without invoking RPC, COM, CORBA, EJB or the like, a true OO design can be near impossible. How do you build objects around queries? Should a list of employees be a collection of employee objects? Should each employee constructor invoke a query to the employee table? Probably not.
**Admittedly, usability and the lack of a good UI for the web is a problem as well.
some questions to ponder
What kind of performance do you need? How many users are expected to use the system? How much data are you going to support? Is data updated constantly or nightly? This doesn't even begin to take into account the fact I have no idea what your existing application does or how it's built.
my best advice
I've found code reuse doesn't occur for web-based apps. Especially if this is in-house stuff. In that case, go for speed. However, if you are attempting to build a marketable product, portability is probably more important. You really haven't given us enough details.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
My experience is that Shit Flows Downhill so head higher up the hill and ask a person more closely involved with the customer, contractor, etc..
This might be a good time for an evolutionary prototype where you create a business tier class that allows for more portability. You then create some PL/SQL, T-SQL , (whatever RDBMS you are using) code and test the performance differences. Show the results to the guy higher on the hill and explain to them the benefits of both solutions. You will soon hear what they truly want. This is also good from a job security standpoint because creating this type of presentation and keeping an email trail can always show that you considered all possible scenarios. Somebody comes to you later on and says "what the f*ck bill? We can't ever get this over to MySql now.. What were you thinking?" You just show them your prototype and email trail and watch them scurry off to bitch at somebody else.
My other experiences have shown me that these guys higher on the hill aren't worth a damn unless they have something they can actually see in front of them anyway.Upgrading software is just as bad as changing vendors. Obviously, the compatibility will be much higher within one vendor's products, but when you change versions of anything (Compiler, RDBMS, WebServer, OS), you have to restest everything! Some places don't do this for patches and such (to their great detriment for that 0.1% of the time when they get f*cked).
Eventually, an upgrade will break your software. So, portability is a concern even if you're CIO is blowing Larry Ellison in his spare time. Different versions of _any_ software can have incompatibilites. Some times patches fix a bug whose side effects your software was counting on. It's a fact.
Portability is not just a cross-vendor or cross-platform concept. It is also a time-based concept within a single vendor.
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
Why is it that nobody seems to pay attention to the fact that an upgrade to a piece of software can be as bad as switching vendors??
It's not like a company is never going to upgrade their databases! Once an upgrade happens, the underlying code has changed... This requires you to retest your application.
Would you rather retest reading data from a table and making sure it hasn't translated into Swahili or retesting all the complicated Business Logic of your application?
I prefer the former...
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.