What so special about PostgreSQL and other RDBMS?

Discussion in 'Ruby' started by Sarah Tanembaum, May 4, 2004.

  1. Part of the beauty of SQL is that there are standards which if you try and stick
    with, you can relatively easily migrate to another solution such as PostgreSQL
    once they reach maturity. PostreSQL really does support a lot, however they're
    missing the speed, tools, and high-availability addons of MS SQL Server.

    For a company that does thousands of dollars worth of transactions per minute,
    such as the one I work for, that $14,000 per processor is a small price to pay
    for the reliability we can get from a commercial app. such as MS SQL Server.

    Do I like the fact that MS SQL Server is closed source? Of course not, however,
    if I had a choice of commercial support providers I would definetly choose
    Microsoft; open source or not. I don't know if you've ever had to use their
    support, but you can get on the phone with them and within a couple hours have
    just about anything worked out. Why? Because they're big, they've seen damn near
    everything.

    I do not believe that closed source software it infallible, however nither is
    open source. Now I'm not going to say that we've never been hacked, because
    saying so will make me out to sound like an ignorant ass. Instead I'll say that
    we are not aware of ever having any problems with our SQL Server being hacked.

    Anyway, down to what matters:
    In the case of SQL Servers, sticking as close to standard sql as possible gives
    you an exit strategy. Extremely vulnerable? I disagree, if Microsoft were to die
    tomorrow by some will of the software gods, someone would just pick up the
    pieces and carry on where they left off. MS SQL Server would be sold to someone,
    along with the licensees, yadda yadda yadda.


    In conclusion I do not agree that using a closed SQL solution makes you
    vulnerable, because there will always be support for you as long as the product
    is still popular. MS SQL Server is very popular, and by the time one might
    consider switching to a new solution, the open source solutions will be large
    enough to be considered viable. Hell, if we're lucky maybe Novell will pick up
    PostgreSQL...
     
    Jeff Rodriguez, May 15, 2004
    #61
    1. Advertisements

  2. Wrong. My argument is that I've taken your "suggestion" long ago.
    It simply doesn't work. Try it sometime.
    As I said before, "a simple function" doesn't do it because
    there are lots of other things specific to a database so that
    the porting to another database won't be significantly eased.
    And, I'm trying to convey this too, there's no need to ease it
    much more because it's not much trouble anyway.
    I'm trying to tell you that whatever API I'm using, the application
    is protected enough against any change.
    It depends on how much performance it costs.

    You started out by saying that maintenance contracts are evil things
    devised by the big companies to suck their customers dry. Now suddenly
    it's obvious that I pay for changes/fixes and that this is a cost factor when
    deciding about an investment.
    That it doesn't make sense to turn me or our company into database specialists.
    That therefore access to the source code doesn't make sense to us.
    Even if we hired some other company, the only thing we need is having *them*
    accessing the source code. If you've done any work under NDA's you'll know
    what a difference this is.
    You are talking ifs here. The contract was as it was and they were right.
    And in what way is that different if mysql AB goes bust and fails to deliver?
    Maintenance is insurance to the database vendor. For a fixed price (or whatever)
    the vendor agrees to do maitenance work. The database vendor obviously
    balances maintenance costs and development costs, trying to minimize both.
    Yes. The same is with open source software. At least if you place a reasonable
    limit on the costs to maintain the open source software yourself. (Reasonable
    meaning it should cost less than a migration to another supported product.)
    Well, looks like the only credible supporter of mysql is mysql ab.
    And right now it works because they all more or less follow redhat.
    Nevertheless, each commercial software gets certified for single platforms,
    therefore you are still tied to a single distribution, or the supported
    subset.
    So, who is the competitor for mysql ab?
    Yes. Doesn't mention support or databases anywhere.
    I had a look at the arcadia case:
    "Key Components
    Software IBM Lotus® Domino(tm)
    IBM Lotus Notes®
    IBM DB2® Universal Database(tm) for iSeries(tm)
    IBM Net.Data®
    Servers IBM iSeries
    Services IBM Global Services"
    So, if I can change the db from oracle to db2 I'm not locked in either.
    That I am supposed to be safer with a bunch of code that, in the case
    I need it, is obsolete or takes time and expertise to get into.
    So what? The right to use it doesn't make me a programmer for that particular
    database. It doesn't make anyone else (short of the original maintainers)
    a programmer for that particular database on short notice. It doesn't make
    the maintenance cheaper than the migration to a still supported database.
    And it definitely doesn't make my boss keep a bunch of abandoned code
    that we are the sole users of.
    I can stop paying maintenance and go somewhere else.
    That "elegance" is more than "abstraction" and means different things
    to different people. And abstraction doesn't always make sense either
    because from a technical point of view one decides for a specific
    product because of the specific properties of the product. If you
    abstract away from them you won't need it either.
    But you always tell me how good it's supposed to be. Well, it is not.
    Oh, I've got the right to use oracle forever too. It's only what I
    want updates that I have to talk to them.
    Your advice. Abstraction means you won't need/use a distinguishing feature.
    This might cost you performance, it costs money to implement, if only that
    feature makes your app possible you simply can't abstract from it and if the
    interface is standardized anyways you don't need to bother either.
    Therefore abstraction is to be decided on a case-to-case base just like
    any other thing.
    No, I'm showing you the contradiction of your arguments.
    If it's easy to change, the case for code rights disappears. Which way do
    you want it?
    But, and that's the point here, if every vendor provided its own patched
    mysql database the customer would be even more pissed off.
    Believe me, it's easier to say "we require oracle" that "we require you
    to run my oen hacked version of MyFavouriteOpenSourceDatabase.
    Are you trying to change thread from opensource to abstraction?
    We do have such an app here. The result is that it doesn't run well
    on *any* database.
    Ah, but I only blame it on larry if it's larrys fault.
    I use a database that can do that and tell them to get the discount
    version if they don't need it. How do you going to accomplish
    that with an open source app where you are the only surviving
    supporter? Just to get back to the open source topic here.
    Why would you have to provide support for a database then?
    Remember you disputed that it's a good idea to let larry provide
    the oracle support.
    So, how many have you under contract and how do your customers
    react to the news that they have to run your own linux distribution?

    In case you've already forgotten, the topic was open source, not abstraction.
    In your case abstraction wouldn't have made sense because you won't ever
    need to change the database because you'd just carry on supporting it or
    buy the best (probably original) developers and go on, right?
    But the abstraction thingie was a nice diversion.

    Greetings!
    Volker
     
    Volker Hetzer, May 17, 2004
    #62
    1. Advertisements

  3. Also, maintenance is more like an emergency ration. If you discover
    it's rotten after the mergency has happened you are in trouble.
    Right. With databases the feature stuff typically gets sorted out in the first
    three months, maintenance took us about the same time (four or five service
    requests) and everything else is a gamble.

    Fortunately we always have some students here resulting in a healthy flow of
    service requests, equivalencing a ration sampling regime.

    Lots of Greetings!
    Volker
     
    Volker Hetzer, May 17, 2004
    #63
  4. That IS the licence agreement. Or at least tke part that deals with after sales stuff.
    That's exactly the link the licence agreement for the database points to when it
    comes to what wecan expect for paying support.
    So? That's what desupport notices are for. The good thing is that
    you find out beforehand, not after you start asking around because
    the latest ftp download is from 1996.

    But what if you required a cucumber with special properties, like a monsanto
    engineered one which contains some drug you want to sell?
    What if you required support in case someone chokes on it and
    the support company requires you only to buy certified cucumbers?
    It's a buying decision. You invest money and get a ware. Open source
    is only different in that you can go behind the stall and see whether you
    can make something of the stuff they dropped. That's where the "for free"
    stuff comes in.
    No, I couldn't because no one else was selling it.
    "> > > > > > The right to modify is a red herring.And this after I just detailed how a migration is made way more difficult by
    all the other bits that change and that the underlying database is really the least of
    your worries when migrating to another app or the same app ten years later.
    I brought up the chip design example because we've been through this.
    I gould give you a board design example we are going through right now.
    System 1 used informix, system 2 uses oracle. Guess what's the only part
    of the migration that doesn' t give us any problems.
    That they should think before they abstract.

    That seems so to you because you can't read back more than one quote.
    You know what, you do that. Use any open source database, and
    ten years after the project has been abandoned you go and port
    it to another platform, and try to get customers to use it okay? Then
    we'll talk again about "forever".
    Depends on how simple and how frequent my requirements change.
    If he's the only guy that understands it I'd insist on maintenance
    and a customizing possibility (like ActiveX or an integrated tcl interpreter).
    If the requirements are volatile I'd do a long term contract detailing what
    money he has to pay for getting out of it.

    By the way, we did a bit of chip design before and had a tool made by a small
    company situated here near Augsburg. Great tool. There we did what I
    said (with the customizing) and we also got the source code. And you know what?
    It was much too much bother even to get it to compile, much less change.
    It was always cheaper to let those guys do the work. And what do you think
    would have happened if we had wanted them to support code *we* modified?
    Because it's erroneus.
    My customers won't want a dead database so I'd have do
    migrate or die anyway.
    Weakening the case for the rights ot the source code.
    As I said before, database migration isn't hard. For our new board design
    tool we developed a database interface from scratch. 4 weeks, including
    testing.
    And yes, we went proprietary because otherwise we'd have spent ages
    doing all the generic layers. And if oracle dies, so what? If our app
    really still exists then we'll spend another 4 weeks interfacing to
    wherever we want!
    Another case on not reading what I write.
    Which database do you have in mind?
    I assume, you mean if my database is abandoned.
    It doesn't matter because I'll be migrating anyway.
    They are dead.
    I can do that with oracle.
    I can't because it's unmaintainable. At least groff is, to stay with that
    example. It already was so in 1993.
    No, you are the one talking rights to the source code. Abstraction is
    just a side tracking because the right to the source code should, in your
    world nullify the need to abstract.
    If the program is fixable it wouldn't get abandoned.
    So, we need the original maintainer org to do the maintenance because only in
    that case you can get one consistent version hosting all apps, right?
    And if the db is dead *all* apps would be dead too, right?
    Where's the difference to a commercial app then?
    The difference is we've been through this and we are using open source
    software and, to go back to the subject line of this thread, open source
    databases for mission critical apps don't work better because of the right
    to the source code. If I find a but in tcl I'll put it the activestate and let them
    sort it out because I'm not going to maintain my own test suite and adapt it
    to every new version. This is even more important for databases where I might
    even not have a means of recovering thedata if my fix results in corrupted data
    half a year later.
    Btw, do you know what ARM paid for gcc support?
    Over half a million bucks if I remember correctly. This for a supposedly
    free product they could have fixed/ported themselves.
    Or broken.
    I can fix a program by telling the vendor to fix it, remember?
    At least I can do that with all the programs we are currently introducing,
    oracle and the said board development tool included.
    Typically they sit at universities and have access to plenty of cheap and
    skilled labour. Sometimes I still envy the TeX group at my old university.
    So, if windows or MacOs is among them I guess you will be dependent
    on some libraries and kernel properties that you don't have access to,
    right? Only I'm trying to learn from you.
    Just you stating it doesn't make it true. People are creative, that means they
    can do things you can't. So to use them you become dependent on them.
    Right. At which we are back to the point where open source doesn't give
    me an advantage. Remember, if I want informix support today I can go to
    IBM too.
    You are mixing something up here. Oracle doesn't depend on
    a single freak but on a well maintained turnover process.
    What you mean is what open source software is famous for.
    Fortunately commercial software rarely depends on one individual.
    But it is powered by lawsuits. At least by the threat of it. Just
    like boeing or airbus are when it comes to engineering security in.
    They buy insurance against lawsuits and, with the insurance company work
    out a process of ensuring quality which keeps the premiums down and
    the insurance from losing lawsuits.
    Doing a maintenance contract and then measuring the few minutes per week
    spending kicking their asses compared with all the programming you'd
    have to do for yourself.

    In that case they'd offer me a migration path too, of course. Also,
    if you ever manage to spend a few dollars on a oracle standard version
    you might want to look at their bug site. Then you'll see to what lengths
    they go. Personally I haven't hit any of those "too obscure" problems
    yet. I've hit a couple real bugs, and once or twice they have nicely told
    me that the problem wasn't what I thought but that my shitty code (first
    steps as a PL/SQL programmer/first steps oracle spatial) crashed the
    parser and that this was fixed in the next release the patch of which
    was available already for download.
    If the main developer company abandons the product how long
    do you think the others will survive? Besides, who tells
    me that the others aren't just passing the service requests on to
    the real one?
    Nusphere takes one branch and supports that.
    Cybertec can't even proper spell the stuff on their homepage.
    So, PostgreSQL Inc would be the one we'd be dealing with.
    I didn't find Nusphere of Cybertec on PostgreSQL Inc's homepage,
    at least not in the partner section. Can't be much love then that's lost
    between them. Which makes me wary about relying on any of those
    other two as a failsafe.
    The fact that it's worth for nusphere to support one port also makes
    me hesitant about PostgreSQL Incs policy re platforms/versions.
    Actually, that depends on how long the bug stays unresolved.
    they escalate bugs. Of course the first guy is there to make sure you've
    read the manual but then you get the development guys.
    No, not "I" get desupported, a product gets desupported. For
    all users.
    All it takes is a poster session at the next oracle world and it
    won't be "just me". At least not if I had anything to complain about.
    I don't need to do that for oracle either. At least not as long as it runs.
    And not, even for a open source software I would wait with the migration
    for the first bug after desupport.
    Databases have customers which are worth a lot. Do you think IBM
    bought them for their marvellous technology?
    Who is CA?
    I'm not repeating again the problems of abstraction. Nor the easyness
    you can migrate between databases today.
    And you can't "toss aside" paying customers. Not sure if you are russian
    and live in russia but if you are and do) you haven't got a particularly nice
    capitalism working over there. Maybe you view problems as ordinary
    that are viewed as pretty exotic in western europe or the US because
    your country really works that way. Rest assured it's not so in the rest
    of the world.
    Ah, but I don't. Besides if I were you I'd leave the evaluation of your
    advice to others.
    "you can solve this with your own wrappers through elegant coding".
    Believe me, it's easier to maintain three supported commercial databases
    than three unsupported (because app-vendor patched) mysql databases.
    there goes again your argument in favour of the private source code
    modification.
    The cool thing is they *still* required oracle. The other cool thing
    is that somehow all the big customers (i.e. the ones with real money)
    aren't really interested in mysql because of all the missing backup/recovery
    and standby tools.
    Per app. With a commercial db *I* tell them which version to use.
    Even this depends. If you are programming exclusively for windows
    it's not a bad choice.
    Please read the first article of that thread.
    No. You are trying to change the topic.
    See above.
    Which ones have you worked with?
    Forget about this okay? A contract gets designed by both parties, even
    if the other side in this case is represented by oracles marketing department
    that actually wants to sell the contracts. To big companies with big legal
    departments.
    And no one forbids me to run oracle and db2 and sqlserver on the smae machine.
    the OS.
    The OS.
    Actually for a database it does not matter what the switch or anyone else
    says. What comes throught the listener is what counts. Look up the oracle
    architecture, or any other commercial one.
    No I haven't. Because having nfs tablespaces isn't good database security,
    because it makes a database dependent on the security of the file
    server. Which is not a network issue.
    You can make a database so insecure that it depends on network
    security. It's a totally different thing.
    Yes, and do you know what people do then?
    They convert the .prn or .ps files to TIFF or
    keep one machine with the original software somewhere in a
    climaticed room and hope like hell the contacts don't rot.
    We do have seven years liability here and storing bitmaps
    of everything is what we do. And recopying them.
    And no, we can't feed them into any current system, if we need to
    deal with any seven year old problem we just print out the stuff
    and look at it.
    If you have that kind of advice to dispense, go and
    ask for a job at Lufthansa or Siemens Medical. They are just
    waiting for people like you.
    See above. Just accept it. You really don't know what you are talking
    about here.
    See above.
    I'm saying is that regardless of the need, daya simply *isn't* permanent
    or portable. Go, ask a bank why they still have the old mainframes running.
    They should have the money to do things proper, right?

    Yes, you changed that one from your original posting.
    "This program has 400 features. No one will be able to use it."
    "Ok, we'll add "ease of use" to the list."
    Data isn't permanent out of choice but because no one has found a good
    solution yet. Go, do your own, get rich. You've got my blessing and me
    as a paying customer if it works.
    It was old and they released it because they've milked it for what it
    was worth.
    Yes. And all the big installations run oracle.
    If they get mysql to their feet support like, we'll have another look.
    Besides, THEY are big enough to buy mysql ab if they want to,
    right to the source code or no right to the source code.
    Also, they invest money to spite oracle, which goes into SAPs market
    by trying to buy peoplesoft. (I'm not saying that SAP's decision isn't
    right, or oracle is blessed, ok?)
    So, access didn't have much to do with it and it certainly isn't cheap
    for them.
    I have put up evidence in terms of real world experience. What you think
    of as banal or not is absolutely irrelevant to me.

    Ok, you are the only one who posts this. OTOH I know the people
    in a lot of other groups and have been corrected by them
    before plenty of times .
    You know, now that you say it it doesn't sound too bad?
    You get a fast, efficient application, can draw on the development and
    support expertise of other large successful enterprises and if your
    customer wants permanency you can actually *ask him* how he would
    have it done without trying to force your solution on him.
    The guy who still writes in TECO assembler? He might know algorithms but
    he sure doesn't know coding.
    Again: I don't have to fix them. I have to have someone fix them. Namely
    the guys I've got the support contract with.
    No one. Who ports mysql to my cellphone?
    The way you misunderstand me I'm tempted to leave everything in.
    Hm. Support from boeing for an airbus.

    I don't care how much they win or lose as long as they fix the bugs.
    Which they do. If they don't, I can still change.
    No. See my other post.
    If not, why do I need the source code?
    Great. We're making headway here.

    Greetings!
    Volker
     
    Volker Hetzer, May 17, 2004
    #64
  5. Sarah Tanembaum

    Quirk Guest

    [comp.databases.ms-sqlserver removed]

    Wow, five days later Volker is still scratching his head about this, I
    though this thread was dead long ago.
    Huh? If you have taken my suggestion, then why did respond to my
    suggestions? Did you imagine, that although I was not responding to
    you, somehow It was you I was talking about? As usual, you make no
    sence.
    'Simply doesn't work' -- an unsubstantantiated out of hand dismissal,
    which is, as anybody with clue knows, a fallacy.

    'Try it sometime' -- Another attempt to portray yourself as having
    greater experience, another fallacy.

    Well, what more can we expect from Volker, the human fallacy?
    The specific proprietary bindings can be wrapped in a simple function.
    Additional functions can be used to issolate proprietry features.
    Thanks for all your effort Volker, but I will continue putting any
    proprietary bindings my own functions, and use those functions through
    out my application, rather than have proprietary binding through out
    my application, and I will continue to recomend that others do the
    same, you do whatever you want though.
    The question was: Why are you bringing up changing the application as
    if it was an argument _against_ my suggestions, since my suggestions
    help protect your applications. Please try to follow.
    I see. So so simple having nothing better to do? This will be my last
    response in this thread then. At least outside the PHP newsgroups.
    Funny, that's what I said. Usualy however, performance concerns are
    not terribly significant and the abstraction can be kept very light
    weight.
    No, closed source licence agreements are so devised. Maintenence
    contracts are perfectly fine.
    You pay for labour, yes, why would this not be obvious?
    I don't know what makes sence for your company, but it should be
    obvious to you that my advice is not directed at your company
    specificaly, and also, my advice is not to become database
    specialists, but rather to not make your own application, especially
    if it is a 'high end commercial application' as described in the post
    I was responding to, exclusively dependend on a third party.
    Access to the source code gives you the freedom to swith 'database
    specialists' even if you never touch the code yourself.

    It also means you never have to stop using the product simply because
    the vendor wants to sell you a new one if the product continues to
    meet your needs, since with source, you can recompile for for a new
    cpu, a new os, or when new security updates are available for the
    libraries it depends on.

    With source, you have the assurance that the product is yours for
    keeps, just like your own code, without source, you have no such
    assurance.
    Yet my advice is for the future, not the past, I see the example given
    as cautionary tale because of the 'ifs'.
    You still have the source code.
    Yet the vendor gaurantees nothing.
    The vendor only tries to maximize profits.
    You do not need to, just like if you design a curcuit with a
    proprietary conector or a standard one, the former is expensive and
    only comes from one comany, the later is cheap and comes from many.
    Unless you really need the former, you would always chose the later.
    In neither case are you required to manufacture connectors.
    There are as many as the market will bear, since there is no
    artificial thing, like closed source, keeping competition away.

    Since the Market is growing rather fast, and big names like SAP are
    promoting it, I see no reason to worry about a lack of support for
    MySQL.
    What? Who follows Red Hat? What does this have to do with companies
    providing development services? What are you blathering about?
    Different products have different cross platform stragies, the good
    ones try and support the widest number of platforms, almost all
    serious database software supports Linux now, including Oracle and
    Sybase. But in anycase, I have no idea how this relates to anything we
    are actualy discussing. Must be something funny in the drinking water
    in your parts.
    Anyone who wants to be, as many as the market will bear, each
    competeting for customers and compentent labour with each other to the
    benifit of the consumer, simple economics.

    Oracle has you trapped because no one else can compete with them,
    since their source is closed. BUT EVEN STILL, I am not recomending you
    never use Oracle, I am only recomending that abstraction is a good
    idea, particularliy when you do not have source.
    As I said, your question was a fallacy, since it was in responce to
    the statement that many companies, including IBM, support open source
    products, the statement did not say that IBM, specificaly, supports
    MySQL, specificaly. Yet, if you wanted to, you could hire IBM to
    support your MySQL implementation, if you had enough money, they would
    be happy to take it. They do not promote themselves as such, and would
    frankly be surprised to get such a contract, knowing that there are
    cheaper alternatives and that MySQL users are not currently the
    typical IBM consulting clients, however, with SAP behind MySQL AB,
    this could soon change.
    That's right, you are only 'locked in' if you can not change.
    If the code is a working part of your application, it is not obsolete,
    however a closed source vendor can obsolete it on purpose to force you
    to buy a new licence. And you need no expertise in it, since if your
    product is popular, like say MySQL, the marker will attract lots of
    competition for your business.
    If it's a working part of a production system, you do not need to be,
    If it is a viable market, there will be programmers for it.
    It may make migration uneccessary by allowing new entreprenuers to
    support it. Competition among them will even make maintenance cheaper,
    and, of course abstraction makes migration, when neccessary, also
    cheaper.

    All this in perfect line with my adivice, as stated in my original
    posting, and as still unrefuted in anyway by you copious blather.
    First, if the system is widely used the code would not be abandoned,
    second, a closed source product is not less likely to be abandoned
    that an open source one, third if it is abandoned then you are in
    better shape if you do have the code.
    You must also stop using the software then, and bear the costs related
    to that.
    I have not attempted to define elegence for different people, only
    given specific examples.
    I never said anything *always* makes sence, all projects have their
    own requirements, I have only given some general advice, good advice.
    No, I tell you that source gives you freedom to chose, but sadely,
    you have trouble understanding simple things. It's probably quite a
    good idea for you to pay Oracle to think for you, in your case, I
    withdraw my advice, however it still holds true for others, mor
    compitent profesionals
    First of all, you do not have any such right, secondly, without
    source, how you will compile it for your new CPU, or new OS, or to
    link a security-updated library?

    Oh never mind, just call Oracle support, you are obviously unskilled
    labour.

    Good luck to you.
    If you do not need to use it, yes, if you do, then //issolate its
    use// in your code with a wrapper function.
    Funny, that's exactly what I said, many times in this thread. Yet
    abstarction is good advice, which is, as I've also said many times,
    all I have offered.
    No, all your showing is your inability to follow a simple arguments.
    The 'case for code rights' does not disapear, but by abstarction,
    becomes less important, since abstarction is another layer of
    protection. This has been clear from my very first post in this
    thread. Keeping your archices in self-contained, self-describing,
    human-readable format was my third recomendation. If you have all
    three, you are in the best shape if your application and/or data has a
    long life span.
    No one is recomending this, that is only your own red herring. The
    customer prerers abstacation when it means that they can use there own
    database, if they only use the database for your application, then
    they see the database as a part of your application, and only want it
    to work.
    Depends on the costumer and wether or not they want to bear of adding
    Oracle to their environement.
    I am not trying to change 'the thread' -- I posted my recomendations,
    which included abstractions, you are responding to them, therefore in
    the discusion between you and I, it is my suggestions that are the
    topic and my only intrest is in defending them, I have no other reason
    to discuss anything with you.
    As I said, there are bad applications, both abstracted and
    unabstracted ones, your argument, is, as usual, a fallacy.
    And, if your forced your customer into Larry's arms, they will blame
    you, not Larry.
    I don't plan on being 'the only surviving supporter', yet another of
    your fallacies, as the producs that I use are popular and their
    popularity is growing, I also abstract my database access, so that if
    this changes, I can change with the dominant trends.

    (I wonder if you even know what a fallacy is, you use so so many of
    them)
    I support my application and all the dependencies that I have forced
    on the client by way of it. If my application fails because of a
    dependency I have chosen for it, the customer will blame me.
    Remember, it was limited to the situatuion where the customers only
    dealt with Larry because of me. For the millionth time, please try to
    follow.
    What on earth are you talking about? I do not need to run my own linux
    distribution. You are a nutcase.
    I made a series of suggestions, including open source and abstraction,
    you responded to my suggestions, therefore the topic is my suggestions
    and your objections to them.
    Well, you might have trouble understanding it, but I think I've made
    it clear that both source and abstraction have their benefits.
    Yeah, a 'diversion' I cleverly included in my very first post in this
    thread.

    What kind of idiot are you?
     
    Quirk, May 19, 2004
    #65
  6. Quirk wrote:

    [snip to cut to the chase]
    [Ditto]

    It seems to me that if you are going to abstract because you lack the
    source code, you are likely not going to be making much use of the
    proprietary functionality you've just spent an arm and a leg on. Which
    strikes me as a waste of money.

    In other words, if you insist on taking out the abstraction insurance
    policy, don't use Oracle, because it's just money down the drain for
    functionality you're never going to use. Yet you say you would not
    recommend never using Oracle. Stripping out the double negatives, that
    presumably means you might recommend using Oracle *and* abstraction.

    Personally, I think my software assurance comes from Oracle's size and
    market share (and my support contract), and I don't need potentially
    crippling abstractions to protect me against their failure at some
    indeterminate and perhaps never-to-arrive point in the future.

    I realise I'm butting in late, but that last post was soooo long, I'm
    fairly confident not one person in 1000 is going to know what the hell
    it was saying!

    Regards
    HJR
     
    Howard J. Rogers, May 19, 2004
    #66
  7. Sarah Tanembaum

    Quirk Guest

    [Oracle and Sybase groups removed]
    Once again, what I asked Volker was to quote the part of the contract
    that Gaurantees him any rights, he was of course unable too, this his
    ugly equivication.
    Again, trying to imply that free sofwtare is likely to not have been
    updated since '1996' is another Fallacy, as is usual form the
    closed-source zealots, since a lot of free software is frequently
    updated, especialy popular packages, just as many closed-source
    software is not updated until you pay for a new version, the
    'Desupport' notice is in this case simply a gun pointed at your head,
    to force you to upgrade, I have no idea why the likes of Volker find
    comfort in these.
    I would avoid depenending on, let alone eating monsanto cucumbers.
    No, in the econonic sence, open source means perfect competion, the
    consumer wins, closed source means a protected market, the consumer
    should beware.
    Yes, there are plenty of people who will fix a bug in GCC for you,
    check the GCC contributors list for a starting point.

    GCC is very widely, and successfully used and many projects large and
    small, that Volker's company was too stupid to use it, tells you much
    more about them, than it.

    Volker can not seem to understand that many applications are different
    than his, than in many cases the application does not change.

    In anycase, if the application is abstracted, migrating is at least a
    little easier, regardless of how much else there is to do, at least
    the code that needs to change is issolated.
    They should think in every case. This was never in dispute. They
    should also think before not abstracting, before chosing a
    closed-source product, before keeping archives in a format that might
    be inaccessable later, thus my good advice.
    No, it is because Volker doesn't have, and have never had a clear
    argument, whereas my argument has been consisted, and every point
    defended since my first post.
    Once again, Volker promtes the fallacious belief that open source
    products will automaticaly have a shorter life span than closed source
    products, and once again, since their is no logical argument that can
    made to support such a wacky belief, he resorts to rhetorical
    pretentions.

    The truth is that popular products will have a longer lifespan than
    unpopular products, and since there are popular open source products
    and unppoular closed source products, his argument is nonsencical.
    Once again, Volker does not understand the need to recompile the
    programm, even when it has not changed, like for a new cpu, a new OS
    of because of security update. Again, I guess I should not expect much
    more from unskilled labour.
    And when he gets hit by a bus?
    Good. clearly, someone in the company has more brains than Volker.
    Having source means the *right* and *ability* to have it modified, it
    does not mean that *need to* or *should* modify it.
    A free databse is not more likely to become a dead database that a
    closed-source database. In fact, bacuese it can survive the death of
    the copyright holding firm, it is less likely to become a dead
    database.

    Yet, if the database is dead, at least with source you can go on, if
    needed, without you can not.
    No, not at all, making a different case to protetc yourself in a
    different, complementary way.
    Changing a few lines of code in one place is easier than chaniging it
    out throught a large application.
    Why does Volker assume I only talking about him and his company, what
    he is qouting is my repeating my original advice, trying to give him
    some context of my original suggestions, that he is, for some
    inexplicable reason, trying to dispute, because he feels my advice is
    not needed for his obscure application.
    The statement asks where "closed-source applications have never been
    abondoned" what makes Volker think I have any particular one one mind.
    And again, my advice including abstraction, makes migrating easier.
    So are most of Volker's brain cells, evidently.
    With closed source applications you can not continue to use it,
    because you can not recompile it for your new CPU, your new OS, or for
    the latest security updates of it's libraries.
    Of couse, the intlegent reader will not that you can and all Volker
    has done is call something 'unmaintainable' with out explaining why.
    No, abstracting, having source code are two good things, having your
    archives in self-contained, self-describing, human readable files is
    thr third suggestion I made, all these are good, all of them
    complimentary.

    Abstraction is, of course, made more important if you do not have
    source code.
    Another fallacy, a program might be abondoned for many different
    reasons.
    No, many orgs can contribute to an open source project, and even
    maintain
    there own forks when needed.
    Only if the case of a close-source db. An open source db can be braugh
    back to life, or in anycase, kept alive in the one production
    environment your applucation needs it, until migration is completed.
    When your closed source db dies, all applications are one security
    update or server upgrade away from dying with it.
    In the case of closed source application, the vendor can ignore you.
    This is idiotic, and outdated characterisation, and of course, another
    fallacy, since it does not respond to the quoted statement.
    I am sure the envy is not recipricated.
    No, an application may support certain envoronments with being
    dependent on them.
    The only point is that VOlker is unable to understand the advantage,
    it seems though that he has a bone to pick and does not really want to
    understand.

    If any others have further questions, I will be happy to respond, but
    clearly Volker is just wasting my time and his own.
    Oracle, like any company, does depend on a few highly skilled people
    who would be difficult to replace, and whole army of unskilled labour
    to take care of the ruitine stuff.
    Good, popular, Open source products, of couse also have a good, and
    quite transperent turnover process, can keep their highly skilled
    contributers throughout there careers, and are aided by a world wide
    user community in taking care of the routine stuff.

    Volker is attempting to portray all free software as being small,
    hobby, projects, but this is hardly the case at all.

    PHP, Apache, MySQL are but a few examples of well organized projects
    that one can certainly relly one.
    PostgresSQL Inc, BTW way is not PostgreSQL Org, but rather a support
    company that is but one contributer to PostgreSQL Org.

    Volker, being unskilled labour, easyly thinks that the next line of
    support os a 'development guy' - -this is not true, you will never get
    a real developer doing support.

    No, for there hostages, I agree.
    Computer Associates.

    Be filled with dread if your platform is baught by them.

    [remaining crap snipped -- I have no more time for this, if I have
    neglecting to respond to a real argument somewhere in it, please bring
    it up again]

    Regards,
     
    Quirk, May 19, 2004
    #67
  8. Sarah Tanembaum

    Quirk Guest

    Hmm. Ok, well, first let me say I am in favour of the Open Source
    databases, so it's a little awkward that I need to defend Oracle here,
    but abstraction does not prevent you from benefiting from Oracle, for
    one, Oracle has proven performance (even with standard SQL), security
    and scalablity advantages that some applications and environment may
    need and secondly, your product may need to run in a customer's
    datacenter, where Oracle is the database they use.

    Also, with lightweight abstraction, such as simple wrappers around
    proprietery bindings, you do not realy lose performance, and when you
    must use prorietary features, you can create additional wrappers to
    issolate these.

    By containing the Oracle bindings to only a few places in your code,
    you make your application far easier to maintain and debug, let alone
    migrate.

    Using a large abstraction object may cause performance issues, but
    using wrapper functions is just good coding in any case.

    And regarding abstraction objects, as far as PHP goes, PEAR:DB seems
    to work well, with not to much lost as far as performance goes,
    although I have not done any major benchmarking, and if performance is
    critical to your application, you should. Ditto for Perl's DBI.
    And the choice is personal, so you are welcome to yours, however, you
    can imagine that not all applications, especialy commercial ones, can
    afford to tie themselves to one exclusive database, and many other
    applications may not want to force there users into using one
    exclusive database.

    Also, your data abstraction functions need not be any more crippling
    than the rest of the application's code, so if coding these will lead
    to crippling the application, likely the application is well on it's
    way to being coded into cripledom already. Also, abstraction will
    generaly (i said //generaly//) have less impact on performance than
    your data model will.
    Yes, I agree. Thanks for the truncation :)



     
     
    Quirk, May 19, 2004
    #68
  9. Sarah Tanembaum

    Galen Boyer Guest

    But then, that application vendor needs to have multiple code
    bases, one to support each platform, each taking advantage of
    that platform's performance characteristics.
     
    Galen Boyer, May 19, 2004
    #69
  10. Sarah Tanembaum

    Noons Guest

    <nit-picking>
    I really wish people would call things by the names they've had for
    decades, rather than inventing new ways to say PRECISELY the same thing.
    Let me provide the example:
    "...but I will continue putting any proprietary dependencies in my
    own functions, and use those functions through my applicatin, rather than
    have proprietary dependencies through out my application..."

    THERE! I've said it. "bindings" means exactly squat outside the world
    of S&M. The correct term is "dependencies".
    Actually, IME performance is the biggest concern. I still have
    to see ONE application built using these modern "concepts" of
    "abstraction" from everything and the kitchen sink that doesn't
    have a serious performance problem outside of demo environments...

    Access to the source code of the database lets you do this?
    I don't think so... I mean, isn't that the whole opposite
    of abstracting implementation details?

    Do what you recommend: wrap your application functionality around
    the available API for the base-layer software, be that db or whatever.
    And that's it. Why the heck would you want to become dependent on
    yet another piece of source code? What's the point of writing
    wrappers in the first place for something you have the source code of?
    But, my dear cyber-friend: no vendor of anything considered
    base-layer software like databases has EVER changed the product
    so much that it broke all previous code! That would be called
    "suicide" in market terms. It's never happened, it will never happen!
    There is NO NEED to work around such an eventuality: it won't happen,
    it's a wasted effort.

    Now, if you have to interface to freeware, I'd be sick worried: there
    is no guarantee whatsoever that some drongo won't go changing everything
    next month. It's happened before many times. It's with freeware that
    you need a STACK of wrappers to protect you from sudden underlying
    code changes! Not with commercial software!
    The question of course being: what the heck do I need that source
    for in the first place?
    I don't think Oracle, nor Sybase, nor M$ are about to go bust any day
    now... Why worry about what might happen in 10 years time if
    the average lifetime of any IT application nowadays is 3 years tops?
    After that it's replacement/upgrade time. It's a waste of time
    and resources to plan any further than that, I'm telling you!
    It's the connector! NOT the entire wiring behind it that you need
    to make portable, isn't it? Like I said: why bother with the
    entire edifice of the source code for a db when all you want
    is the API?
    Precisely. So, why bother with the source code that lets you
    manufacture connectors? See what I mean?
    Now you lost me: ANYTHING that SAP promotes is emminently
    objectionable and suspicious, IMHO! THERE is an example
    of a totally proprietary company, if I ever saw one....

    I BEG your pardon? Care to rephrase that? Since WHEN is
    availability of source code ANY measure of competitiveness
    or existence of competitiveness? Exactly where have you been
    hiding if you think no one competes with Oracle? Helloooo???? :)
    I'll agree with that. Put SAP behind anything and it stops
    being cheap and competitive...
    Don't confuse "making it obsolete" with "making it inoperational".
    The two things are worlds apart. I drove a 15 year old car
    for YEARS!
    No one will, old chap. It's called upgrade lifecycle. You are
    wasting a lot of resources and work making yourself obsolescence-free
    in a society that made obsolescence a way of life about 30 years ago.

    All this to say: I understand your motivation and it makes sense
    in terms of engineering concerns. But, there is one thing called
    (I hate to use a common place) "real world".
    Wasted effort, in today's real world, to try and make an IT product
    obsolescence-free.
    Yeah sure. But abstraction doesn't mean over-complicate your work
    by taking in even more source code! Abstraction is used PRECISELY
    to reduce the amount of source code you have to worry about. That
    is what an API is for!
    Now, that's the spirit!!!!! :)
    Anyways I'm coming in late on this one, so reply only if
    you could be bothered. I just thought I'd throw in a few thoughts
    prompted by some things you said that rang a bell.

    Cheers
    Nuno Souto
     
    Noons, May 19, 2004
    #70
  11. Sarah Tanembaum

    Joel Garry Guest

    Actually, I have seen both small and medium sized software companies
    that have real developers doing support. With small, it hopefully is
    obvious why, with medium, sometimes it is a policy of broadening the
    employees experience, and sometimes it is due to the politics of
    different groups seizing power and banishing those of a different
    viewpoint to support. (I'm not talking about frontline or helpdesk
    support here.)

    With Oracle, I presume there are large organizations of both support
    and development separated by a Chinese wall, but ocassionally I get
    some back end support where the person seems very developer oriented -
    I don't know whether it is simply someone bucking for a developer job,
    or just working on replicating bugs gives them an insight, or what,
    but it is invariably very useful to talk to such a person.


    jg
     
    Joel Garry, May 20, 2004
    #71
  12. Guys, Guys....
    Calm down.
    The propositions put forth by Quirk are becoming lost in a tide of acrimony.

    Proposition 1:
    There are circumstances under which my client is better protected against
    commercial or accidental events, if he possesses source code to the
    application and the underlying database management system.

    I agree with that proposition.

    Proposition 2:
    There are circumstances under which my client is better protected against
    commercial or accidental events, if I have coded my application in such a
    way (by use of a database abstraction layer) that migrating my application
    to a different database management system is made very easy.

    I agree with that proposition.

    Proposition 3:
    There are circumstances under which my client is better protected against
    commercial or accidental events, if he has a human readable backup of the
    database of the type Quirk describes.

    I agree with that proposition.

    Note that neither Quirk nor I claim that these propositions always apply to
    every situation, nor that there are not clear and obvious exceptions.

    However, I must take issue with Noons, who states:

    There are large companies in our industry who are famous for implementing
    backward-incompatibility in new versions of their software. Further, most
    support is time limited: once the software has reached a certain age, the
    vendor demands that you upgrade (at your cost) if you want to continue to
    receive support and bug fixes. Clearly, that makes good commercial sense and
    nobody would dispute their right to drop suport for old products, but it
    does lock customers into an "upgrade or else" cost cycle. If a customer
    decides not to upgrade, the vendor has effectively broken the code for the
    customer as soon as the next bug or insecurity is encountered: no support
    means no fix.

    The point here is that current commercial practice by many vendors forces
    clients into expensive upgrades which have no direct commercial benefit to
    the customer. Quirk's propositions present a scenario under which customers
    have the freedom to choose what to upgrade and how much to spend, based on
    their own business imperatives and not those of a third party on which they
    depend.

    After 25 years in the industry, I know of many organisations which are
    getting heartily sick of spending vast sums of money in knee-jerk upgrades
    (which usually involves staff retraining and other ancilliary expenses) at
    the whim of a vendor. When I am able to offer my customers an alternative to
    this revenue drain, I am happy to do so. It is not always possible or
    appropriate, but when it is, the benefits are exactly as Quirk has laid out.

    Your mileage may vary.

    Kind regards,
    Doug Hutcheson
     
    Doug Hutcheson, May 20, 2004
    #72
  13. Commercial applications often must tie themselves to one exclusive
    database. For example, the last inhouse database application I worked on
    was a medium sized one -- 50 (wo)man years of developer time. Management
    decided to use a three tier model, but then had us push all of the
    functionality possible down to database access using Oracle's PL/SQL.

    The decision was based on the need for performance and scalability in
    dealing with several tables with over 10 million rows each in a web based
    system expected to handle several thousand requests per hour.

    Processing demands frequently dictate that commercial applications be
    tightly coupled to a commercial vendor's proprietary tools and processing
    languages. To do otherwise would produce a system that could not be
    guaranteed to meet performance requirements.

    I like MySQL (and I prefer PostgreSQL to MySQL), but when it comes to
    creating an application that absolutely, positively must provide high
    performance on a 24/7 basis I would opt to use Oracle or IBM's DB2 because
    I know that either can provide me with whatever support I require (all it
    takes is money), their products perform well, and their products are so
    scalable that using either I can develop on a lap top running under
    windows and move my code -- with no changes -- to a multi-mainframe
    monster with as many disk drives as the customer can afford.
     
    Jerry Gitomer, May 20, 2004
    #73
  14. On Thu, 20 May 2004 00:00:48 +0000, Doug Hutcheson wrote:


    Big snip here
    Doug,

    If you are dealing with the right vendor the cost of upgrades is included
    in your support contract. When I was an active DBA working with Oracle
    and Informix all I had to do was make a phone call and the manuals and
    media for any currently supported version magically arrived -- at no
    charge -- within a week. I would install the latest version on my test
    system and see if the developers or quality control people ran into any
    problems -- they never did. I would then install on the development boxes
    and after a couple of weeks of complaint free (well, as complaint free as
    developers ever are) work I would install on the production systems and
    provide the operations staff with a set of scripts that made the new
    version the active one and tested it to run after the backup was
    completed. (Just in case I had them keep the back up in house instead of
    sending it out for off-site storage the next morning -- but I never ever
    needed that backup.)
    Eureka, a painless and inexpensive upgrade.

    To summarize there was no incremental cost for either software or manuals.
    Since I was on salary there was no additional labor cost to install and
    test a latter version.

    Jerry
     
    Jerry Gitomer, May 20, 2004
    #74
  15. It, and the ones that follow are somewhat lost in the fact that it is
    largely meaningless.

    Proposition 1a.
    There are circumstances under which my client is better protected against
    commercial or accidental events, if he possesses a contract with a
    financially stable vendor of the application and/or underlying database
    management system.

    Is exactly as true as Proposition 1. Define the circumstances. then relate
    them to the real business world.
    Proposition 2a

    There are circumstances under which my client is royally screwed if he has
    an app that does not take advantage of the platform on which it is running,
    even if this means being dependent upon that platform.
    Why do the words filing cabinet come to mind :(
    Well I don't see anywhere that Quirk makes these assertions - though i do
    see him claiming that open Source is a better model that closed source.
    Where can I get the security & performance fixes for linux kernel 1.5 - I
    don't want to upgrade?

    Your suggestion about backward incompatibility also seems to confuse
    Microsoft Office with platform software. Even MS - to whom I assume you
    refer - have platform software that is backwardly compatible for the last 5
    years or so.
     
    Niall Litchfield, May 20, 2004
    #75
  16. Sarah Tanembaum

    Joel Garry Guest

    [cdos put back in for those not using google to say that]
    Those of us following the Oracle groups on google still see it in the thread.

    jg
     
    Joel Garry, May 20, 2004
    #76
  17. I've got some long test runs with not much to do in between, that's
    why I spend a bit of time here.
    You implied that I didn't run the contract by our law department.
    You did talk to me. Read up your article .
    Substantiation: When cygnus supported gcc, who else did?
    So, what's your experience?
    So, how do I isolate functional or bitmap indexes? How do
    I isolate the queuing mechanisms of oracle?
    "> > See my other posting. Compared to changing the application (replacing"
    "> > it with another), changing the underlying database is easy."
    If you are that forgetful maybe you shouldn't cut out that much.

    If I buy oracle (or purify) or whatever, I buy a fixed price for the
    product *once* and the maintenance annually. There is no
    sucking dry part.
    I'm trying to make it obvious to you that I can pay for the labour perfectly
    fine without having the right to the source code. It's what those
    perfectly fine maintenance contracts are for.
    Ok, somehow you seem to think 4 (ok, at most 5) weeks migration
    effort is an exclusive dependency justifying staying away from db2
    or oracle. I guess that depends on the apps you are developing.
    See above.
    And where are the security updates for the obsolete database?
    Where are the customers that want to buy a piece of legacy code?
    See above.
    Yes, I can print it out and kill some trees with it. Somehow
    you still think I will become a database developer or can convince
    my boss to pay for the support of an obsolete application.
    He guarantees to put labour to my service requests.
    Btw, what does mysql guarantee if you take out a service contract
    with them?
    Yes, and where is the contradiction?
    Just checking... All the databases we are talking support sql, or at least
    a reasonable subset of it right? So, by using sql I'm only tying those
    parts to the particular db that are special and which I use, right?
    So, the only "own investment" is tied to those features because I need them,
    right?
    This might sound unusual for you, but if you use a great library, and suddenly
    it has a bug and there's no maintenance, the app is bust. Now, what are the cases
    here:
    - I'm poor. So, neither could I pay for the fix, nor for the company. My
    product depends on someone richer to pick up the pieces. (the code
    or the rights to the code)
    - I'm rich. So, either could I agree to pay more maintenance and keep
    the vendor alive, or pay a few percent less (by cutting out the management
    level of the vendor) and hire the developers to go on.
    - I'm a programming genius. then why did I use a library in the first case?

    Closed source is nothing artificial either, it's the only way to
    go before you have payed the original developers.
    If I were using SAP and not worried about recovery beyond restoring
    last night's backup I'd be using SAP/MySQL too, if I could send
    my MySQL bug requests to SAP.
    The Linux distributors. As an example of a big open source project.
    And that postgres windows company does the same, right (following
    the main postgres company)?

    Btw, spelled out: I *CAN'T* hire "many companies, large and small"
    to support my open source product. For most, none exist, for some,
    one exists, tying me down, for very few, some companies support
    ports, some simply cash in.

    Also, I've had my share of support by small companies. They have
    no way to make all customers pay a flatrate, they *always* bill
    by the hours, and they don't support new platforms if they differ
    from the current Dell pc because that's all they can afford.
    No, thanks, I'll stay with the biggies, and right now the only open source
    biggie is RedHat for the OS and no one for databases. However,
    if SAP buys MySQL AB that would make mySQL a real contender
    in the database business.
    The connection is that somehow the development has to be coordinated
    because otherwise you won't have one project anymore but a bunch of
    quickly diverging incompatible branches.
    So, there are de facto owners. For Linux most commercial
    software vendors make sure that their stuff works with redhat and the other
    distributors scramble to make their distributions as compatible as
    possible. Of course, each adds some bells and whistles, like a nice config
    tool or checks whether all the packages work, but that's more or less it.
    We are discussing vendor dependencies. And if you buy a commercial
    linux product it typically says something like "RedHat Linux 7.2, 7.3, 8.0,
    Enterprise AS 2.1, 3.0", not "guaranteed to run on any kernel you manage
    to drag from the internet and compile on the PDA of your choice".
    In other words, no one.
    What open source projects does IBM support, i.e. offer maintenance
    for?

    Btw, many companies support closed source products too, typically
    their own. Some offer more, they are called consultants. So what?
    If I go out now into your nice shining world, what do I see?
    - Mysql: Mysql AB, with SAP sponsoring development.
    - Postgres: one sham, one windows only supporter and the owner
    So, regardles of what you wish for, If I depend on an open source
    database for its features or whatever I'm still tied to one supporter.
    If I had that kind of money I could have them implement my feature in DB2 too,
    right?
    At which point, your support requests still land at the same company regardless
    of whether the bug form has mysql or sap on it.

    So can an open source vendor. Remember, I'm not beating up
    a dead horse.
    He can't. The only thing he can do is stop bothering about my bug
    requests (mysql ab can do that too) and tell the world that this
    product is obsolete (mysql ab can do that too).
    What marker? And my product isn't mysql it uses it. (or,
    oracle, in that case)
    See above, that paragraph about me being either rich and poor and how
    the right to the source code is irrelevant.
    If it's a viable marked the original support wouldn't have gone bust.
    Oh yes! And this doesn't work at all with closed source, see informix.
    And the product more expensive and slow in the first place.
    I really love the way you congratulate yourself more and more often.
    Oh, I did refute it, you just ignored it. And asked me to help you forget
    by quoting shorter, right?
    Ditto for a commercial product.
    It is. Because someone invested real money in it.
    Sigh... We've been through this. In what way am I in better shape then?
    It doesn't make sense to wait for your mysterious entrepeneurs (who, in
    any case could also bid for the property of the bust company) and
    then we can reduce the problem to how do I as the sole left paying
    guy get some support from someone other than the original supporter.
    Which gives me the possibilities outlined above in the rich/poor stuff.
    Ditto for open source. Remember, I leave when my bugs won't
    get fixed, regardless of open/closed source.

    You should become a consultant.
    To choose what exactly? Any supporter out of one?
    I do. Witness all the 8.* and 7.* installations still around. Desupported
    ages ago.
    Even with the source, if I were to compile mysql to, let's pick
    a platform at random, my new cellphone, I'd have to do a bit
    more than ./configure&&make install, right? In fact, I'd have to go
    though all the code, look for any system calls, get to know my
    target system and how the system calls differ subtly, and
    still I'd have a much lesser chance of making it work than if the
    original maintainers did it.
    Where? (I mean, before I pushed your nose in it?)

    So, what are code rights good for if not for not having to change
    the database?
    So my code gets clumsy and slow for no reason at all.
    To anyone else apart from you too?
    Oh yes, we've been through that too. Send me an email
    once you've done this so I can redirect our ISO9000 auditors
    to your webpage.
    You are recommending this. Or, rather it follows from your recommendation.
    An open source db stops getting maintained and every appvendor start to
    do his own maintenance, resulting in a bunch of uncoordinated fixes.
    And this is so, because the business case for a coordinated patch
    and release management has disappeared.
    The customer prefers to use his own database. How the vendor deals
    with it is not his problem. *Our* problem right now *is* such an abstracted
    product, which doesn't run properly on oracle because those guys never
    tested it with an UTF8 database, much less ISO dates. From hindsight
    we'd even accepted sqlserver if they had done it properly.
    As for other abstractions, we've seen plenty of products available for
    several platforms and the first question is "what is your main development
    platform?" and that's typically what we'll use too because we are really
    sick of Mainwin, mks toolkits where every path has a different \ or /
    convention or Java apps which need three tries each time I try to
    start them. (Before you ask: that's abstracting from the OS, ok?)
    Yes. Then *you* will optimize your costs, looking for a partner who
    can support your database. At which point we are at the maintenance
    question. Again.
    See the subject line.
    In what way?
    Yes, and if oracle isn't willing to fix it I can give oracle a lot more trouble
    than mysql because their contracts are more expensive.
    You should have read the next paragraph before responding.
    So, what was this "right to the source code" stuff about?
    And that somwhow doesn't work for commercial databases,
    right?
    And somehow this relates to open source.
    Whatever your secret work experience may be your public english
    experience isn't good enough to teach me that language.
    Actually no. The point B was (and it's still in here for you to read)
    that the customer trusts Larry more than me.
    But you are right if we open a case D), "I force my customers
    into oracle because I get a percentage or something", my customers
    would be right to complain.
    Cut out this stuff. It makes you sound ridiculous.
    About how you solve that problem for your customers.
    Then you depend on some linux vendor.
    For you, simplified: You are deperately seeking a case where open source
    beats closed source. If you can take someone elses distribution you are
    dependent on him and need your customer to run that distribution. (Correct
    me if all your programs consist of perl scripts and don't load any shared libraries.)
    If no one else exists (any more) do your own support, directly or by hiring
    others, yet still you need the customers run your OS.
    Abstraction is irrelevant to open source because the big thing is the right
    to the source code, correct? And due to the small migration work
    while moving from one sql database to another it's irrelevant to closed source
    too. It's impossible if you depend on special features of your database. In that
    case your customer knows it and is with you.
    See above.
    What's the difference? You didn't start the thread.
    How old are you?
     
    Volker Hetzer, May 21, 2004
    #77
  18. Sarah Tanembaum

    Quirk Guest

    Thanks Doug, it's nice to know that there are one or two actual
    developers in these groups, but anyway, I think it's pointless to go
    on discussing these things in this thread, it's pretty clear to me we
    are dealing with zealots and those looking for genuine answers have
    likely stopped reading long ago, I'll avoid argueing with them and
    instead stick to giving good suggestions, the readers can make up
    their own minds, as they should in any case.

    You summary of the issues should be enough for those with real
    questions, I'll add a few comments and leave it at that.
    And also note that simply issolating database functions in your code
    is a easy and light way to abstract data access, just to make this
    clear for those that keep insisting that database access abstraction
    means automaticaly including a third tier:

    For instance, in pseudocode:

    function myapp_query(query)
    if not connected
    prop_connect
    result = prop_query(query)
    for each result
    data(ii++) = prop_fetch(result)
    if not set cleanup
    set cleanup connection callback
    prop_disconnect
    return data

    That is a very simple wrapper, an abstraction object like PEAR::DB is
    a lot more complex, but that works for simple issolation assuming
    standard SQL, we issolate the use of the proprietry bindings
    ('prop_*') to one function, and convert our result set into a standard
    array, manage openning our db connection and register a callback to
    close, all in one place.

    Not using SQL as the argument, but rather a more general request
    describer is a further abstraction that makes your application
    cleaner, but that is another subject, which if there interest, I
    could explain in more detail.

    Then you have your application:

    function myintreface()
    global data
    data = myapp_query(<query>)

    function myview()
    global data
    for each data
    display data (ii++)

    function mydetail(key)
    global data
    display data(key)

    And so on...

    The functions themselves only use the wrapper, 'myapp_query', and a
    native array, 'data'. So, if your application has hundreds of
    functions that use the wrapper function and/or the native array, and
    only a few functions where the proprietary bindings are issolated, you
    can migrate much easier, or even take advantage of new features in
    your existing platform more quickly, because you have issolated the
    data access code.

    I even use such a data access wrapper when I do use a data abstraction
    object, it keeps my code cleaner, and I can even change the
    abstraction object if I like, even, when needed, (*gasp*) intoduce
    another tier.
    And, of course, a self contained, self describing, human readable file
    is also usefull when the data has a long life span, and may in fact
    out live the application and the platform, or when the data needs to
    be shared with other organisations and their applications.
    That's right, these are suggestions, each application has its own
    requirements, this is why at first it was confusing to me why the
    likes of Volker scream and shout that these suggestions are bad
    because it deosn't suite their application (or so they think), but
    then it became pretty obvious since Volkers most recent drivel, where
    he argues with the subject title of the thread instead of my arguments
    and claims that my arguments are an attempt at diversion, even though
    I have maintained them form my first post. The likes of Volker are
    just rabid scum, and talking to them, and the other zeolots just
    distracts from the topic and likely drives away any readers who are
    generaly interested in the topic being discussed.

    Regards,
    Dmytri Kleiner
    my initials at trick dot ca will reach me
    (I don't live in Canada anymore though)
     
    Quirk, May 22, 2004
    #78
  19. Sarah Tanembaum

    Quirk Guest

    Thanks Nick, your alternative propositions are much clearer than the
    FUD of the other posters. Although, your attitude seems no less
    belligerent, so my hopes for a fruitfull discusion are not high.

    In the real business world, outside of major corporations (and
    sometimes even there), closed source software is either used
    comepletely illegaly or seriously overdeployed, thus support from the
    provider is unavailable or limited to simple telephone support.

    The applications are generaly supported by consultants, who are
    aquired directly or from
    consuting agencies and not development firms.

    I'm not saying that this is always the case, or is your case, but it
    is the real world you asked about, and that's it.

    Having source, and using free software is becoming more and more
    common in these cases, and it can be assumed that many of the people
    asking questions in this news
    group are working in such environements.

    So, when the question of Free versus Propietary Databases is asked, I
    think it is important to help people understand the advantages of
    having source, or using free software, of avoiding dependencies, *as
    well* as comparing features.

    As I said in my article in the NonProfitTimes, wether or not a
    particular peice of free software is better that a particular peice of
    nonfree software, free is better than stolen.

    If you can guarantee that your legel relationship with your vendor
    will never break down, for financial or any other reason, then yes,
    you can get away with not abstracting, and not having source code.
    This, however, is not the real business world. Only a tiny, wealthy,
    fraction of it.

    If you have source code, as you do with free software, you can always
    find a way forward, because you are not dependent on a relationship
    with any single entity.
    Issolating your data access code does not mean you can not take
    advantage of the platform, it means that all your data access code is
    in one place, meaning that you can more easily change your
    application, for instance to migrate it, or for instance to *make
    better use of the platform you are running*
    Because your companies record keepers distrust your closed-source,
    unabstraced application's data so much that they insist on keeping
    their trusty paper records.

    With proper electronic archives as I've described, they will soon
    enough be conviced to replace the filing cabinets with datacabinets,
    but it will take some convincing, since after years of dealing with
    developers like Volker (my new synonym for unskilled labour), and
    losing access to their data, they rightfully do not trust the
    datasystems.
    Open source is a better model than closed source, but that is not the
    subject here, a particular piece of open source software,m such as a
    database platform, MAY OR MAY NOT be better than a particular piece of
    closed source software. I am not disputing that things like Oracle are
    good software, only trying to help those making such a choice
    understand there are other things to consider than simply comparing
    Oracle against MySQL.
    You are equivicating here on the difference between installing more
    recent software and paying for a new licence, one is not the same as
    the other.
     
    Quirk, May 22, 2004
    #79
  20. Sarah Tanembaum

    Noons Guest

    It's a pity that you have considered my reply as that of a zealot.
    I did concede a few points and debated yours in a civilized fashion.

    However, thanks for giving me the opportunity of stating this in a less
    civilized language (remember: YOU started the language, not I): none of
    your points is by definition a "world truth". You don't provide a single
    supporting argument that does not involve your interpretation of what
    software makers would do rather than what they in fact do.

    Your stupid deduction that somehow only your view of the world is worthy
    the title of "developer" defines you as the idiotic and moronic type of
    geek that thinks the world was invented yesterday by your kind and all that
    came before is just amateur effort. In character, I might say.

    You and your little group can go and drop dead as this thread ends
    here for me: I don't have time to argue ANYTHING with "kewl" people.
    Not worth the effort: the worst disasters in IT development I've ever seen
    in 30 years of career have been prompted by your kind and I don't like
    my name associated with that sort of unprofessional reputation. It
    never pays in the long run.

    Goodbye and keep developing for a non-existent market. It has a
    brilliant future. And yes, I DO have a future and nothing you can
    possibly do will stop it.
     
    Noons, May 22, 2004
    #80
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.