On 3/24/2013 10:21 AM, Charles Polisher wrote:
John Slee wrote:
Edward Ned Harvey wrote:
I agree with you, and I agree with what I said, that you disagreed
with. ;-) We just have apparently a different perspective on what
you're likely to do in the future
Yes. IME companies are far more likely to switch applications than to
switch databases and keep the same application. So what was the point
again?
FWIW $EMP is a software company that sells apps tied to one DB product.
This has never to my knowledge been a sales blocker. The customers see
the DB as a "background" requirement and if they're not familiar with
the DB platform (eg. if it's not what they use for their other apps) we
help them out.
There's far more to this mythical database platform agnosticity than the
mere proclamation of "yay, no SQL errors!"
There are levels of agnosticity. When database knowledge is
tightly coupled into application logic you inherit the same set
of problems that come with tightly coupling data representation
and display. MVC and other design patterns are commonly used to
ward off such problems. An example of the dangers lurking in
closely coupling a database to an app: my shop's multi-million
dollar ERP has a key feature based on a port from Visual Firefox
replete with fixed-field data, thus inflicting maintenance costs
onto a new database platform. We absorb these costs in
application licensing fees. Any vendor entering this market
won't need to pour resources into this brittle nightmare, so
they'll have a competitive cost advantage.
Those in the #lopsa channel on IRC have seen some of the "fun" I have at
work with a particular piece of software from a vendor and how it uses
the database.
The software was originally written using a complete IBM stack.
Websphere, DB2 etc, but by the time we partnered with them to use the
software with a particular partner they'd switched to MySQL as the back
end. Unfortunately MySQL's query optimiser is nothing like DB2s
(probably more accurate to say no query optimiser is like any other),
and queries that run fast on DB2 might not run fast on MySQL and vice versa.
In particular, DB2 presumably handles sub-select queries really well,
something MySQL historically hasn't. The developer has a particular
fondness for all-in-one queries, cramming an entire complex business
logic into a single statement, which results in sub-select queries that
might run some 15+ layers deep and drag the server to its knees.
Thankfully both MariaDB and MySQL 5.6 have mostly fixed that quirk, and
switching to the former was trivial fairly early on in the process.
That reduced a significant amount of pain whilst we've worked with the
vendor to improve things.
Paul
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
