> A few years back, I converted a chat/gallery portal system Ethereal Realms (http://www.erealms.org/ > from MySQL to PostgreSQL, since at the time it was felt that features like proper referential integrity > and stored procedures would really pay off.
> The code was shortened considerably, was more stable overall and the OpenBSD port compiles properly without > threading issues. However, despite all of those advantages and the database server being on a bigger > server with more memory performance suffered considerably.
Hmm, given that labor is the primary cost to most projects and not hardware this seems like a fantastic trade-off. And given that this was years ago (v7.1?) the hardware trade-off might not even apply any more.
Also note, that if you're doing a small number of reads on MySQL ISAM tables and comparing that to Postgresql 7.1 you could see a performance impact. About the same one that you'd see if you moved to MySQL's innodb tables. In other words, data integrity sometimes comes at a performance penalty.
Most other comments similarly irrelavant due to older product version.
> Vacuum? That concept alone can throw people in for a loop, especially when designing a system > which is meant to be run by people with no technical experience. So you have to code in a serious > amount of intelligence into the application or rely on Auto-Vacuum (not available at the time) > which can slow performance down even more.
Only extremely non-technical people should be thrown a loop by vacuum:
- you're getting a bonus on write-performance by asynchronously reorganizing your tables via vacuum
- vacuum can work concurrent with users
- schedule it to execute during low-use periods of time
- similar things are done in other large scale commercial databases
What's the hard part? Scheduling something to run periodically? What!?! Don't you run backups periodically? Don't they impact performance a little? Of course they do. The complaint about vacuum amazes me - how can people have such a hard time with a cronjob?
>> Great, "rich query languages" that wrap richer query languages.
> No, in some cases the portable query language is more featured that the language it wraps. JDOQL > implementations can provide rich querying even on systems with no built-in query language (like filesystem storage).
That makes sense - and does sound somewhat valuable.
> Is there any modern standard for SQL that is fully supported by any vendor? No.
The ANSI SQL standard has levels of compliance. For typical queries on typical databases (not perhaps mysql which often disregards ANSI) the standard is well supported.
> What they don't want to have to do is to re-implement thousands of those complex queries in order to migrate to another database product.
Hmm, having perform many ports between database products I can honestly say that I've never bumped into this problem outside of SQL Server/Sybase stored procedure insanity. The most often case is 10% of your queries might require a tweak. 1% might require a rewrite. So, to avoid this you wrap the entire language in an entirely new language? That itself can't support 100% of the features of the first, and isn't usable by everything that supports the first?
>>But maybe that's why we've never seen a powerful reporting tool come out of the java community?
> No - you have never seen a powerful reporting tool. This does not mean there aren't any. There are plenty. > JasperReports is a good one.
After doing reporting for twenty years across many projects I've seen most reporting tools out there. If you consider JasperReports powerful then you really don't understand reporting. It's just a report painter - not much different technology than we were using in 1989, and that Crystal Reports has provided for 10+ years. It's the wrong way to deliver reporting, rather than use metadata-driven reporting that can automatically allow the users to wander through an n-dimensional cube of data, the programmer laboriously creates individual reports. Yuck.
> I think posters really need to do some more research before commenting on matters like this > - I keep reading posts like this that bear little relation to reality.
Hmm, I think people should actually learn how to use databases before coming up with ingenious work-arounds like:
- Object Oriented Databases - that can't handle sequential scans, reporting, searching.
- Hierarchical Databases - reinventions of technology thrown away in the 80s.
- XML as a database - completely misses concepts of ACID, concurrent users, sequential scanning
- wrappers to help programmers avoid learning the lingua franca of databases (SQL)
Sorry to be so negative towards your point, but I've been on multiple J2EE projects where programmers adopted some brilliant idea like OODBMS, container managed pesistence, or sometimes just EJBs - only to discover later that the way that the java community thinks about data only covers about 50% of its needs.
> Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability. > You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to > high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability, > the ability to do this means you get high-quality SQL largely automatically.
Great, "rich query languages" that wrap richer query languages. That are highly portable across databases, but themselves are not portable across application layers (do *any* reporting tools support them? is there an ANSI standard for ORMs?)
When a developer needs to run adhoc queries in order to diagnose problems with data in a database, to test impacts of schema migration, etc - do they write SQL or application code? Keep in mind that these are not likely to be simplistic queries...
If you want all the flexibility of SQL, does it make sense to completely wrap one language in another - when you really don't get 100% portability? Or is this really just a solution that slightly simplifies things for 50% of the problem space - for those developers who refuse to learn SQL?
Seriously SQL isn't the greatest language in the world, but I have a hard time understanding why anyone that works with database applications can't handle complex queries. It's like someone working on the linux command line that refuses to learn bash. Or like a web developer that refuses to learn HTML and just uses FrontPage instead.
And aside from the "When in Rome" argument, consider the benefits of learning a data-oriented approach to working with data. SQL is more different from java, python or ruby than lisp is. One of the best things a programmer can do is to to become fluent in multiple different types of languages. Compare SQL's set-based logic to lisp or python. Learn to think of data in terms of sets and aggregates instead of just one row at a time. Until you do that you'll never understand reporting, which is really about how to answer basic business questions. But maybe that's why we've never seen a powerful reporting tool come out of the java community?
The other part is simple incompetence. I worked at US West for an eight month contract in the late 90s, and found that in my 24 years of IT experience it was *by far* the worst run company I had ever seen. They had 6,000 engineers that just reviewed 3 foot tall stacks of reports every month to find problems in the COs. And management had absolutely zero concern for what was good for either their staff or the customer. Zero. Don't even bring up the customer word at meetings with them or they will look at you like you're an idiot.
I think the best thing that could have happened to us was to have *more* regulation and break these companies up completely. Then rebuild. MCI & Sprint were well-run companies before WorldCom was allowed to buy out MCI.
the cost of long-distance dropped dramatically *because* of MCI - not AT&T. Remember when calling long-distance meant something? That was back in the old days of MA Bell: back when it cost a friggin fortune. And calling overseas was out of the question for most people it was so expensive.
And in terms of innovation, Bell Labs of course produced some valuable ideas. But were they still producing great ideas in 70s & 80s? You've got to create at least one great idea a *decade* if you expect to be given a monopoly/tax for what? A hundred billion dollars a year at today's rate?
Frameworks are great when they provide 100% of your needs and very little of your non-needs.
But when they fail to provide a few of your requirements they become a jail. You just might not be able to do something at all, and will certainly spend much more time on implementation than if you didn't have a framework at all.
The agile manifesto (www.agilemanifesto.org) does a great job of stating that we need to be adaptive and resiliant rather than try to anticipate the future:
Responding to change over following a plan
And this directly conflicts with frameworks in my opinion - since a framework could be a great fit today, but a tight enclosure tomorrow.
Seriously, I'd start them out with primitive technology, for a few reasons: 1. computers are gradually becoming just slightly more interactive versions of televisions for many people 2. it doesn't cost and arm and a leg to provide them simpler tech 3. yesterday's greatest toy is often every bit as good as today's greatest toy, minus a few pixels
As far as computer use goes, I let my two boys start with simple educational kid games. Then they got to play a few arcade games - like NetHack (which taught them the keyboard). Now they like simulators and flashier games like tuxracer. But now (ages 8-12) they're also playing around in wikipedia, using gimp, open office, etc.
I wouldn't mind a timer though, that would limit how long they can use the computer every day. It hasn't become a problem yet, but we're headed towards conflict on that subject.
> I lean heavily on PHP because most of the people I work with know it, or they know enough C/Perl to get through it. Lots of admins > getting hired that get lost in bash scripts. I'm sick of getting out of bed to fix things just because someone can't muddle through > sed. PHP lets me sleep more. Between the baby in the crib and the one's working the help desk I'm getting a bit puffy eyed..
understandable - i think folks often underestimate value of a large pool of potential programmers:-)
I've got a data warehousing project that used php for the exact same reason. Then went with python on the backend instead of java for similar reasons. Well, we actually had java programmers to start with, but it was faster to train new folks on python and build the ETL solution than to just build it in java.
> SSI HA setup
what's this? I've worked on MPP machines like SP2s, but not familiar with this term...
> Last I checked, you didn't have to pay any "licencing fees" to use it (innodb).
MySQL pays licensing fees to use it for non-gpl work - then passes that on to the customers. I've got no clue how this applies to the odd licensing exceptions, etc but that's my general understanding of the agreement.
> This seems to apply even whether the copy was had by fair means or foul, since the licence comes from the copyright holder and not the downstream distributor.
Sure, good point - I'm not sure where this code exists, but assume that it is available.
> If Oracle won't add the features you mention to InnoDB, then somebody else will
I agree that this could happen for small features, but many of these are huge (partitioning, query parallelism, etc) and won't be added by an individual, but instead a team - consisting of people familiar with this functionality. And not a team spending a few hundred hours, but maybe up to 10 or 20 thousand. And that's just for a single feature like table partitioning. Where do you get such a team from? There are few out there with prior experience. So, maybe you get 1-2 core people from? Oracle, IBM? Actually, the postgresql team would be good to look at here. If not for recruiting, to get an estimate of the time needed to support certain features.
> I can't even find what the the license cost for MySQL I have vague recollections of something about $250.00 for a commercial > license free for non profit. On the web site there is a $595.00 survice contract, but no mention of a commercial use license.
MySQL Network Basic is $600/server/year: https://shop.mysql.com/ You *may* not have to pay anything however. But that depends on GPL/LGPL licensing complexities, and you will probably need a lawyer to know for sure (MySQL AB recommends just buying a license if you're confused).
In comparison, Oracle/DB2/SQL Server are free for small databases, regardless of how you use them. Then if you need to license it can still be cheaper than mysql - since they typically have an initial license (say, $750) and then just 18%/year afterwards. All three of these databases can be *far* more expensive, but db2 in particular can also be cheap in many configurations. I'm running a terabyte-sized data warehouse on about $28k in total licensing. Compared to the cost of the hardware this is nothing.
> So I can only assume that those of us that need a database and not even a feature rich database will simply move on to something > else or pony up the $5000 to $40000 to have a DB to keep track of the CD collection.
No, you're fine for several reasons:
- you can probably get by with the free mysql version for now
- postgresql is completely free
- sqlite is completely free - and is probably the best choice for a tiny project like this
- oracle is completely free for something of this size
- db2 is completely free for something of this size
- sql server is completely free for something of this size
Unless of course you're talking about building a competitor to cdnow, in which case you will face some costs;-)
> This because it didn't include the kitchen sink of 10 years of "bright ideas" to synergize the enterprise with scalable robustness. > You can include in this set of bright ideas, things like transactions (which many complex database applications really can't > do without), and things like running a JVM within the database. No one has ever been able to coherently explain to me why it would > be a good idea to do the latter (save as some workaround to a convoluted/broken legacy database they don't have the option of fixing).
You're mixing two different classes of database features:
essential - features that have been relational standard fare for about 24+ years. While you *could* develop a database without these features you will be wasting a vast amount of time in almost all cases: you'll be continually reinventing the wheel, won't be able to port any applications to it, and even simple queries will be difficult. In other words, don't even waste your time unless you're merely putting together a recipe database.
- transactions
- views
- unions
- subselects
- highly standard sql
- temp tables
- etc
optional - more recent database features (ok, well for many of them 10+ years). These aren't critical IMHO, but without them it will seriously limit what you can do with the database. Without some of them support for third-party applications will suffer and you simply won't be able to port some apps.
- jvm in the database
- xml support
- clustering
- partitioning
- query parallelism
- stored procedures
- triggers
- user-defined functions
- materialized views
- automatic query rewrite
- online backups
- online maintenance
- etc
Regarding JVM in the database - in my opinion this is a result of a couple of things - the desire to integrate the database more closely with the app, to enable developers to use the same technology in the database as in their application, etc.
For an example of one possible use - I've just found myself recommending java stored procedures on a db2 database - in order for us to give a stored procedure interface to another team to develop against. I don't trust them to write queries, and our prior application (php) isn't ideal for creating an integration layer. So, even though I typically avoid running business logic of this type in the database, it's an example of how that feature will allow us to easily transition two applications to a single api.
> Just because the makers have been bought out, does not mean that there is any threat to the Open Source nature of the code. Quite the reverse, > in fact. If Oracle are trying to make the proprietary fork of MySQL more compatible with their own proprietary database, then they must > be aware that there is no way they can prevent the open source fork also becoming compatible with their proprietary product.
Right. However, the best option for them is to simply sit on the products. Don't do anything - except maybe raise licensing fees. They'll be able to do that very soon now for innodb. In the meanwhile, MySQL needs innodb to support advanced database features if it is going to be more competitive with Oracle - partitioning, encryption, online maintenance, etc. And if Oracle just refuses to add any of these new features then MySQL really has no where to turn. They're effectively *stopped*. For at least a few years anyway.
> Oracle have shot themselves in the foot here. There is already plenty of choice of Open Source database server > applications; MySQL, PostgreSQL, Firebird, SQLite, Ingres, and so on.
Sure, but mysql is the market leader, and oracle has completely taken the wind out of its sails. While Postgresql is a better product in almost all ways it doesn't have the PR machine that mysql has - so it would take a couple of years for postgresql to get the same buzz/hype that mysql has going. Of course, oracle can't really hurt postgresql the way it has hurt mysql, but that doesn't matter - harming mysql gives it a good 2-3 year benefit.
> This could be the beginning of the end of closed source software. We can only hope!
I think Oracle is in deep trouble, but really not for another 5-10 years. And I think this actually gives them a couple of extra years.
> When the InnoDB purchase was announced, I asked MySQL CEO Mårten Mickos: you're going to write your own transactional back-end now, > aren't you? Mickos is loath to announce that, but it's a no-brainer. The database back-ends in question handle file storage and > low-level query operations, don't understand SQL, and are plug-ins - ready to be unplugged and replaced by some new transactional design by MySQL.
There's a reason he's loath to do this - it will require revenue to be spent on hiring people who know how to pull this off. Further - it will take him a few *years* to develop a backend as mature as Innodb. As soon as he states this strategy Oracle will likely respond with this message.
> But MySQL has an alternative to rolling their own back-end: they can continue to use the InnoDB and Sleepycat products under their > Open Source licenses, which are valid forever and for anyone, instead of the commercial licenses that MySQL currently has for these > products. Because MySQL is a server, physically separate from its client applications, the GPL and its restrictions won't be a > consideration for MySQL's customers.
Great, so the backend would be even further removed from the rest of their database. Rather than being ingenious, this split between MySQL and its storage engines causes:
- inconsistencies for users (storage pool specific ddl)
- poor resource utilization for servers (separate memory pools)
- difficulty for optimizer to consider storage engine specifics in query plan
- difficulty in mixing multiple storage engines within single query
- necessity in getting storage engine providers to support MySQL features
- partitioned tables?
- online changes?
- how about ability to add a column without copying & reloading all rows?
> Open Source developers will code elsewhere, replace whatever Larry holds close, and create new businesses.
Unfortunately, powerful databases are large and complex beasts, and take years to get right. As much as I can understand why folks would flee from Larry, I think he'd be quite pleased if the mysql team were to go off and spend another five years recreating it.
As much as I'd like to think that the open source approach can resist this kind of ploy, once a company goes commercial, I really don't think it can. The far safer option now is SQLite for anything small, and Postgresql for anything large. Oracle can't touch these, you don't need a lawyer to determine your licensing costs, etc.
> And a population of 60 million people only produces a limited supply of highly-skilled mathematicians, no matter how much education you throw at them.
Especially if you send the message that they need to work for less than they could get selling shoes. Why bother becoming a mathematician in that case?
Now, lets say that you were to pay them a reasonable salary that would enable them to live comfortably in their community. You might just discover that far more people would pursue it.
> The supply of mathematicians doesn't magically increase just because you decide to pay them more. If there are 10000 available > mathematicians in the UK and 20000 are needed, then 10000 jobs must be outsourced, no matter how much the UK employer decides to pay.
Sure, but the market will typically adjust to meet these needs. Eventually, the field becomes well-rewarded and attracts more candidates - qualified people who were otherwise going into engineering, etc for the better pay & opportunities.
Another problem with this claim is that we've seen it used disingenuously far too many times by corporations trying to claim that there aren't enough programmers in the US - when they're obviously just trying to put a PR spin on their outsourcing.
my first was a 360/50:
- cardpunch for a UI.
- code reuse was actually card deck reuse
- if you were fast and lucky you *might* get four program runs a day
- desk-checking your code was critical - there were no debuggers
- 512k of memory - required that cobol compiler was unloaded before running cobol programs
- probably 20 to 40 different tape and disk units
- wrote code to be fast rather than easy to maintain
it was a good experience, but python & linux are so much more fun than cobol on a mainframe!
> Don't want to be harsh, but I happen to work with plenty people that have the same kind of reasoning as you gave, adding complexity, > questions and red herrings to escape making decisions or proposing concrete solutions.
The problem with your approach:
> if previous_value > 10000 and current_value > previous_value*10 then > ask for validation by authority > endif > The '10000' and the '10' should be in the static data of the application.
is that it is an arbitrary static threshold - based on gut reaction and probably never to be updated. It'll either be so high that it is almost never used, or so low that it generates tons of false positives. This is why a statistical approach is far better - just compare the increase in value to the increase in value of all the other homes. If > 3std then trigger your exception action.
Of course, if you can get the user to accept a deviant workflow to handle these approvals, then fine. In my experience the realization that you need this often happens late in a project, and they won't want to make any changes at this point. That's why I'd recommend a data quality approach instead, which is easier to add on (again, in my experience).
> Why wouldn't a financial management/accounting system have similar rules enforced and monitored?
I think the issue is that most people seek to address data validation problems through simple business rules such as "no property can be over $20,000,000 in value"
- in which you know that sooner or later this rule will become obsolete
or they try to add additional workflow steps such as "any property worth over $10,000,000 must be validated by supervisor prior to be added to property rolls"
- in which people disagree about workflow, the extra complexity & cost usually cause it to be killed
Personally, I prefer for data like this to keep a separate data quality attribute that gets flagged due to certain checks - and not necessarily boolean logic either - something like - if the value of this property is three standard deviations over all other property values then flag it as abnormal. Now, anything flagged as abnormal should then cause additional flags to trip so that it's easy to draw people's attention to this problem.
Then again, hell - there's also the use of extremely simple trending reports - which should have made this obvious. Didn't anyone get a little curious about this county having its total property value increase an average of 2% every year for 50 years then increase 10% (or five times the historical average) in a single year? Just guessing at the numbers here, but come on - it should have been glaringly obvious to anyone responsible for finances in the city. And that's without using this application at all.
> rest assured that Apple planners were well informed of this when they made the decision to switch
Not necessarily: IBM is a vast bureacracy and the left hand often has no idea what the right hand is doing. Additionally, this method may have been recently pushed ahead suddenly after some recent successes.
>>Both postgresql and mysql lack query parallelism, > Wrong. Most query work is done in parallel, hardware permitting. Queries cannot be run on multiple CPUs at once (at present), > which is what you're referring to, but that's very deceiving. CPUs are generally not the bottleneck, in databases it usually has a lot more to do with RAM and disk.
When referring to query parallelism I'm talking about it in the same context that you'd use on db2, oracle, informix, teradata, sql server, and probably sysbase: having the database engine split the query into parts and run them simultaneously to take advantage of multiple CPUs.
And in my experience (on db2, oracle, informix) this leads to linear performance improvements - at least up to 4 CPUs. This is the difference between 60 second tablescans and 15 second tablescans - a huge difference.
> [PostgreSQL lacks] any kind of partitioning, > Wrong. Have you seen version 8.1 with constraint exclusion? It's been out for a while now.
I've used the same methods with oracle, db2, and sql server. I'd definitely use it if I was using postgresql today, but in my experience every implementation has been a pain in the butt to use.
> Where's the evidence? don't look at me - there's no TPCs for postgresql
> If you put PostgreSQL on nice hardware with RAID and perhaps replication, just like Oracle, I would expect the results > to be fairly mixed and inconclusive. Some things Oracle would win, some thing PostgreSQL.
I'm sure you're right - there must be some combinations of hardware and application domain in which postgresql would come out on top. There certainly are combinations of application domain, business size, budget, availability requirements, data volumes, and team skillsets - in which postgresql comes out on top.
> I'm sure there are problem domains where PostgreSQL just won't fit and Oracle will, but I don't think you acurately > characterized those domains.
The domain I mentioned above (reporting, data warehousing, business intelligence, data mining) is one that I've got fifteen years of experience with. I'm sure I'll eventually be using postgresql for this as well, but think there's little value in fooling ourselves about how honest oracle sales staff is, how fun to work with ibm is, or how well suited to large data postgesql is.
> As far as SAP they released MaxDB which is what they base SAP on. MaxDB and MySQL are very closely related.
in what way? If I'm not mistaken MaxDB is the renamed SAPDB which is the renamed Adabas - an old crufy pre-relational database from the early 80s. I remember thinking it was obnoxious around 1985.
> Guess which database hasn't had any issue (at least that I know of) MSSQL. Kind of opposite of what you would expect huh?
Not really: mysql's normal behavior is to silently truncate, silently convert, silently ignore problems. It will often happily chug along through invalid calculations that other servers would stop immediately at.
And it is far easier to administer. Oracle used to be a real bear to design and administer for, though that's changed substantially over time - especially with 10g. In the old days if you didn't have the right skills available you could get in very bad trouble with oracle. It's still true, but to a much lesser extent. Part of the reason is the extreme configurability: you can tweak almost everything. With mysql you can tweak very little in comparison - and often memory pools that should be joined are actually separated (wasting valuable memory). But it's simple.
But I wouldn't put my critical business apps on mysql - even if it is simpler to admin. The designers showed a careless disregard for data quality. They've cleaned it up some, but not completely.
> OLAP would be better served by "lighter" databases, not OLTP.
What gives you that impression?
Consider that (R)OLAP doesn't benefit much from btree indexes - which are ineffectual for selectivity of greater than 2% of your data. That is, if you want to analyze 100% of the data for a single month in a database with 12 months of data @ 1,000,000 rows per month - a btree index won't be useful in just selecting one month of data. Partitioning will be useful - but you're only going to get that from db2 or oracle (or on sql server's immature implementation at ~$30k/cpu now). Light databases won't support it. Right off the bat you just took a 12x performance penalty by going with the lightweight product.
And when postgresql/mysql scan that 12,000,000 rows - they're doing it single-threaded. Even if you're on a four-way server. Whereas db2 or oracle can parallelize that query - giving almost a linear performance improvement. That's another 4x performance penalty you took by going with a lightweight product.
In other words, db2 or oracle would have been about 48x the speed of postgresql or oracle in this common olap scenario. And that doesn't even get to optimizer maturity (will bury mysql), memory tuning, OLAP functionality, materialized views, etc, etc, etc.
Some day the lightweight products will get there. Of course they won't be so lightweight when they do;-).
> Actually, unofficially of course (thanks to Oracle's license), PostgreSQL is well known for beating Oracle in many small to > medium size databases. Feel free to ask around. It's not hard to find people that performed their own shootouts of PostgreSQL > vs Oracle and picked PostgreSQL because the performance was equal or better at a fraction of the cost.
In my experience this usually occurs because it takes more expertise to tune oracle than mysql, postgresql, or sql server. But this isn't to say that Postgresql isn't fine for many applications - the performance that oracle/db2/etc offers isn't always necessary.
> Simple fact is, parallel queries are not going to save you anything on simplistic queries...etc..etc...
Actually, I find that in many applications being developed today it is no longer adequate to merely rehost an app from one technology to another. It has become necessary to deliver some analytical components within even simple applications. For example, in a typical simple transactional application now you may log everything that occurs (ten years ago you never would have done that), and provide totals, running averages, etc to show data broken out over time by category, etc. This isn't rocket science, but requires a great optimizer, query parallelism, and partitioning to run quickly.
> You'll find many people that contribute to PostgreSQL by actually picking another DB...and the developers are fine with that.
> If IBM cannot find the generosity to release a 'free' version of a defunct operating system
OS/2 is rumoured to use third-party software licensed by IBM from Microsoft - that they can't open source. How does this make them "not generous"?
> The DB2 free version is probably some sort of scheme for getting lock-in to the platform and is not just an example of generosity by IBM.
Lock-in? Well, getting mindshare at least. Which puts them in the same company as:
- sql server (free extremely limited database version)
- oracle (free extremely limited database version)
- mysql (free vaguely-defined database version)
The only database products that I'm aware of that don't do this are Postgresql and Firebird. Neither of which match db2 for performance. And nor did this free version of db2 just suddenly appear - they had a very low-cost version for a few years.
Slashdot Mirror
> A few years back, I converted a chat/gallery portal system Ethereal Realms (http://www.erealms.org/
> from MySQL to PostgreSQL, since at the time it was felt that features like proper referential integrity
> and stored procedures would really pay off.
> The code was shortened considerably, was more stable overall and the OpenBSD port compiles properly without
> threading issues. However, despite all of those advantages and the database server being on a bigger
> server with more memory performance suffered considerably.
Hmm, given that labor is the primary cost to most projects and not hardware this seems like a fantastic trade-off. And given that this was years ago (v7.1?) the hardware trade-off might not even apply any more.
Also note, that if you're doing a small number of reads on MySQL ISAM tables and comparing that to Postgresql 7.1 you could see a performance impact. About the same one that you'd see if you moved to MySQL's innodb tables. In other words, data integrity sometimes comes at a performance penalty.
Most other comments similarly irrelavant due to older product version.
> Vacuum? That concept alone can throw people in for a loop, especially when designing a system
> which is meant to be run by people with no technical experience. So you have to code in a serious
> amount of intelligence into the application or rely on Auto-Vacuum (not available at the time)
> which can slow performance down even more.
Only extremely non-technical people should be thrown a loop by vacuum:
- you're getting a bonus on write-performance by asynchronously reorganizing your tables via vacuum
- vacuum can work concurrent with users
- schedule it to execute during low-use periods of time
- similar things are done in other large scale commercial databases
What's the hard part? Scheduling something to run periodically? What!?! Don't you run backups periodically? Don't they impact performance a little? Of course they do. The complaint about vacuum amazes me - how can people have such a hard time with a cronjob?
>> Great, "rich query languages" that wrap richer query languages.
> No, in some cases the portable query language is more featured that the language it wraps. JDOQL
> implementations can provide rich querying even on systems with no built-in query language (like filesystem storage).
That makes sense - and does sound somewhat valuable.
> Is there any modern standard for SQL that is fully supported by any vendor? No.
The ANSI SQL standard has levels of compliance. For typical queries on typical databases (not perhaps mysql which often disregards ANSI) the standard is well supported.
> What they don't want to have to do is to re-implement thousands of those complex queries in order to migrate to another database product.
Hmm, having perform many ports between database products I can honestly say that I've never bumped into this problem outside of SQL Server/Sybase stored procedure insanity. The most often case is 10% of your queries might require a tweak. 1% might require a rewrite. So, to avoid this you wrap the entire language in an entirely new language? That itself can't support 100% of the features of the first, and isn't usable by everything that supports the first?
>>But maybe that's why we've never seen a powerful reporting tool come out of the java community?
> No - you have never seen a powerful reporting tool. This does not mean there aren't any. There are plenty.
> JasperReports is a good one.
After doing reporting for twenty years across many projects I've seen most reporting tools out there. If you consider JasperReports powerful then you really don't understand reporting. It's just a report painter - not much different technology than we were using in 1989, and that Crystal Reports has provided for 10+ years. It's the wrong way to deliver reporting, rather than use metadata-driven reporting that can automatically allow the users to wander through an n-dimensional cube of data, the programmer laboriously creates individual reports. Yuck.
> I think posters really need to do some more research before commenting on matters like this
> - I keep reading posts like this that bear little relation to reality.
Hmm, I think people should actually learn how to use databases before coming up with ingenious work-arounds like:
- Object Oriented Databases - that can't handle sequential scans, reporting, searching.
- Hierarchical Databases - reinventions of technology thrown away in the 80s.
- XML as a database - completely misses concepts of ACID, concurrent users, sequential scanning
- wrappers to help programmers avoid learning the lingua franca of databases (SQL)
Sorry to be so negative towards your point, but I've been on multiple J2EE projects where programmers adopted some brilliant idea like OODBMS, container managed pesistence, or sometimes just EJBs - only to discover later that the way that the java community thinks about data only covers about 50% of its needs.
> Also, unlike Rails, they are extremely portable. You aren't restricted to a subset of SQL to get portability.
> You can use a full and rich query language (like JDOQL 2.0) and that is automatically translated to
> high-performance vendor-specific SQL for whatever database you are using. Even if you don't want portability,
> the ability to do this means you get high-quality SQL largely automatically.
Great, "rich query languages" that wrap richer query languages. That are highly portable across databases, but themselves are not portable across application layers (do *any* reporting tools support them? is there an ANSI standard for ORMs?)
When a developer needs to run adhoc queries in order to diagnose problems with data in a database, to test impacts of schema migration, etc - do they write SQL or application code? Keep in mind that these are not likely to be simplistic queries...
If you want all the flexibility of SQL, does it make sense to completely wrap one language in another - when you really don't get 100% portability? Or is this really just a solution that slightly simplifies things for 50% of the problem space - for those developers who refuse to learn SQL?
Seriously SQL isn't the greatest language in the world, but I have a hard time understanding why anyone that works with database applications can't handle complex queries. It's like someone working on the linux command line that refuses to learn bash. Or like a web developer that refuses to learn HTML and just uses FrontPage instead.
And aside from the "When in Rome" argument, consider the benefits of learning a data-oriented approach to working with data. SQL is more different from java, python or ruby than lisp is. One of the best things a programmer can do is to to become fluent in multiple different types of languages. Compare SQL's set-based logic to lisp or python. Learn to think of data in terms of sets and aggregates instead of just one row at a time. Until you do that you'll never understand reporting, which is really about how to answer basic business questions. But maybe that's why we've never seen a powerful reporting tool come out of the java community?
> Yes? No? Maybe?
Partially
The other part is simple incompetence. I worked at US West for an eight month contract in the late 90s, and found that in my 24 years of IT experience it was *by far* the worst run company I had ever seen. They had 6,000 engineers that just reviewed 3 foot tall stacks of reports every month to find problems in the COs. And management had absolutely zero concern for what was good for either their staff or the customer. Zero. Don't even bring up the customer word at meetings with them or they will look at you like you're an idiot.
I think the best thing that could have happened to us was to have *more* regulation and break these companies up completely. Then rebuild. MCI & Sprint were well-run companies before WorldCom was allowed to buy out MCI.
the cost of long-distance dropped dramatically *because* of MCI - not AT&T. Remember when calling long-distance meant something? That was back in the old days of MA Bell: back when it cost a friggin fortune. And calling overseas was out of the question for most people it was so expensive.
And in terms of innovation, Bell Labs of course produced some valuable ideas. But were they still producing great ideas in 70s & 80s? You've got to create at least one great idea a *decade* if you expect to be given a monopoly/tax for what? A hundred billion dollars a year at today's rate?
One more point:
Frameworks are great when they provide 100% of your needs and very little of your non-needs.
But when they fail to provide a few of your requirements they become a jail. You just might not be able to do something at all, and will certainly spend much more time on implementation than if you didn't have a framework at all.
The agile manifesto (www.agilemanifesto.org) does a great job of stating that we need to be adaptive and resiliant rather than try to anticipate the future:
Responding to change over following a plan
And this directly conflicts with frameworks in my opinion - since a framework could be a great fit today, but a tight enclosure tomorrow.
Seriously, I'd start them out with primitive technology, for a few reasons:
1. computers are gradually becoming just slightly more interactive versions of televisions for many people
2. it doesn't cost and arm and a leg to provide them simpler tech
3. yesterday's greatest toy is often every bit as good as today's greatest toy, minus a few pixels
As far as computer use goes, I let my two boys start with simple educational kid games. Then they got to play a few arcade games - like NetHack (which taught them the keyboard). Now they like simulators and flashier games like tuxracer. But now (ages 8-12) they're also playing around in wikipedia, using gimp, open office, etc.
I wouldn't mind a timer though, that would limit how long they can use the computer every day. It hasn't become a problem yet, but we're headed towards conflict on that subject.
> I lean heavily on PHP because most of the people I work with know it, or they know enough C/Perl to get through it. Lots of admins
:-)
> getting hired that get lost in bash scripts. I'm sick of getting out of bed to fix things just because someone can't muddle through
> sed. PHP lets me sleep more. Between the baby in the crib and the one's working the help desk I'm getting a bit puffy eyed..
understandable - i think folks often underestimate value of a large pool of potential programmers
I've got a data warehousing project that used php for the exact same reason. Then went with python on the backend instead of java for similar reasons. Well, we actually had java programmers to start with, but it was faster to train new folks on python and build the ETL solution than to just build it in java.
> SSI HA setup
what's this? I've worked on MPP machines like SP2s, but not familiar with this term...
How does a zend buyout affect sqlite? Sqlite is public domain, and has a nice little community around it.
Just out of curiosity, why php?
> Last I checked, you didn't have to pay any "licencing fees" to use it (innodb).
MySQL pays licensing fees to use it for non-gpl work - then passes that on to the customers. I've got no clue how this applies to the odd licensing exceptions, etc but that's my general understanding of the agreement.
> This seems to apply even whether the copy was had by fair means or foul, since the licence comes from the copyright holder and not the downstream distributor.
Sure, good point - I'm not sure where this code exists, but assume that it is available.
> If Oracle won't add the features you mention to InnoDB, then somebody else will
I agree that this could happen for small features, but many of these are huge (partitioning, query parallelism, etc) and won't be added by an individual, but instead a team - consisting of people familiar with this functionality. And not a team spending a few hundred hours, but maybe up to 10 or 20 thousand. And that's just for a single feature like table partitioning. Where do you get such a team from? There are few out there with prior experience. So, maybe you get 1-2 core people from? Oracle, IBM? Actually, the postgresql team would be good to look at here. If not for recruiting, to get an estimate of the time needed to support certain features.
Probably the best
> I can't even find what the the license cost for MySQL I have vague recollections of something about $250.00 for a commercial
;-)
> license free for non profit. On the web site there is a $595.00 survice contract, but no mention of a commercial use license.
MySQL Network Basic is $600/server/year: https://shop.mysql.com/
You *may* not have to pay anything however. But that depends on GPL/LGPL licensing complexities, and you will probably need a lawyer to know for sure (MySQL AB recommends just buying a license if you're confused).
In comparison, Oracle/DB2/SQL Server are free for small databases, regardless of how you use them. Then if you need to license it can still be cheaper than mysql - since they typically have an initial license (say, $750) and then just 18%/year afterwards. All three of these databases can be *far* more expensive, but db2 in particular can also be cheap in many configurations. I'm running a terabyte-sized data warehouse on about $28k in total licensing. Compared to the cost of the hardware this is nothing.
And of course, postgresql & sql
- http://www.postgresql.org/
- http://www.sqlite.org/
are completely free.
> So I can only assume that those of us that need a database and not even a feature rich database will simply move on to something
> else or pony up the $5000 to $40000 to have a DB to keep track of the CD collection.
No, you're fine for several reasons:
- you can probably get by with the free mysql version for now
- postgresql is completely free
- sqlite is completely free - and is probably the best choice for a tiny project like this
- oracle is completely free for something of this size
- db2 is completely free for something of this size
- sql server is completely free for something of this size
Unless of course you're talking about building a competitor to cdnow, in which case you will face some costs
> This because it didn't include the kitchen sink of 10 years of "bright ideas" to synergize the enterprise with scalable robustness.
> You can include in this set of bright ideas, things like transactions (which many complex database applications really can't
> do without), and things like running a JVM within the database. No one has ever been able to coherently explain to me why it would
> be a good idea to do the latter (save as some workaround to a convoluted/broken legacy database they don't have the option of fixing).
You're mixing two different classes of database features:
essential - features that have been relational standard fare for about 24+ years. While you *could* develop a database without these features you will be wasting a vast amount of time in almost all cases: you'll be continually reinventing the wheel, won't be able to port any applications to it, and even simple queries will be difficult. In other words, don't even waste your time unless you're merely putting together a recipe database.
- transactions
- views
- unions
- subselects
- highly standard sql
- temp tables
- etc
optional - more recent database features (ok, well for many of them 10+ years). These aren't critical IMHO, but without them it will seriously limit what you can do with the database. Without some of them support for third-party applications will suffer and you simply won't be able to port some apps.
- jvm in the database
- xml support
- clustering
- partitioning
- query parallelism
- stored procedures
- triggers
- user-defined functions
- materialized views
- automatic query rewrite
- online backups
- online maintenance
- etc
Regarding JVM in the database - in my opinion this is a result of a couple of things - the desire to integrate the database more closely with the app, to enable developers to use the same technology in the database as in their application, etc.
For an example of one possible use - I've just found myself recommending java stored procedures on a db2 database - in order for us to give a stored procedure interface to another team to develop against. I don't trust them to write queries, and our prior application (php) isn't ideal for creating an integration layer. So, even though I typically avoid running business logic of this type in the database, it's an example of how that feature will allow us to easily transition two applications to a single api.
> Just because the makers have been bought out, does not mean that there is any threat to the Open Source nature of the code. Quite the reverse,
> in fact. If Oracle are trying to make the proprietary fork of MySQL more compatible with their own proprietary database, then they must
> be aware that there is no way they can prevent the open source fork also becoming compatible with their proprietary product.
Right. However, the best option for them is to simply sit on the products. Don't do anything - except maybe raise licensing fees. They'll be able to do that very soon now for innodb. In the meanwhile, MySQL needs innodb to support advanced database features if it is going to be more competitive with Oracle - partitioning, encryption, online maintenance, etc. And if Oracle just refuses to add any of these new features then MySQL really has no where to turn. They're effectively *stopped*. For at least a few years anyway.
> Oracle have shot themselves in the foot here. There is already plenty of choice of Open Source database server
> applications; MySQL, PostgreSQL, Firebird, SQLite, Ingres, and so on.
Sure, but mysql is the market leader, and oracle has completely taken the wind out of its sails. While Postgresql is a better product in almost all ways it doesn't have the PR machine that mysql has - so it would take a couple of years for postgresql to get the same buzz/hype that mysql has going. Of course, oracle can't really hurt postgresql the way it has hurt mysql, but that doesn't matter - harming mysql gives it a good 2-3 year benefit.
> This could be the beginning of the end of closed source software. We can only hope!
I think Oracle is in deep trouble, but really not for another 5-10 years. And I think this actually gives them a couple of extra years.
> When the InnoDB purchase was announced, I asked MySQL CEO Mårten Mickos: you're going to write your own transactional back-end now,
> aren't you? Mickos is loath to announce that, but it's a no-brainer. The database back-ends in question handle file storage and
> low-level query operations, don't understand SQL, and are plug-ins - ready to be unplugged and replaced by some new transactional design by MySQL.
There's a reason he's loath to do this - it will require revenue to be spent on hiring people who know how to pull this off. Further - it will take him a few *years* to develop a backend as mature as Innodb. As soon as he states this strategy Oracle will likely respond with this message.
> But MySQL has an alternative to rolling their own back-end: they can continue to use the InnoDB and Sleepycat products under their
> Open Source licenses, which are valid forever and for anyone, instead of the commercial licenses that MySQL currently has for these
> products. Because MySQL is a server, physically separate from its client applications, the GPL and its restrictions won't be a
> consideration for MySQL's customers.
Great, so the backend would be even further removed from the rest of their database. Rather than being ingenious, this split between MySQL and its storage engines causes:
- inconsistencies for users (storage pool specific ddl)
- poor resource utilization for servers (separate memory pools)
- difficulty for optimizer to consider storage engine specifics in query plan
- difficulty in mixing multiple storage engines within single query
- necessity in getting storage engine providers to support MySQL features
- partitioned tables?
- online changes?
- how about ability to add a column without copying & reloading all rows?
> Open Source developers will code elsewhere, replace whatever Larry holds close, and create new businesses.
Unfortunately, powerful databases are large and complex beasts, and take years to get right. As much as I can understand why folks would flee from Larry, I think he'd be quite pleased if the mysql team were to go off and spend another five years recreating it.
As much as I'd like to think that the open source approach can resist this kind of ploy, once a company goes commercial, I really don't think it can. The far safer option now is SQLite for anything small, and Postgresql for anything large. Oracle can't touch these, you don't need a lawyer to determine your licensing costs, etc.
> And a population of 60 million people only produces a limited supply of highly-skilled mathematicians, no matter how much education you throw at them.
Especially if you send the message that they need to work for less than they could get selling shoes. Why bother becoming a mathematician in that case?
Now, lets say that you were to pay them a reasonable salary that would enable them to live comfortably in their community. You might just discover that far more people would pursue it.
> The supply of mathematicians doesn't magically increase just because you decide to pay them more. If there are 10000 available
> mathematicians in the UK and 20000 are needed, then 10000 jobs must be outsourced, no matter how much the UK employer decides to pay.
Sure, but the market will typically adjust to meet these needs. Eventually, the field becomes well-rewarded and attracts more candidates - qualified people who were otherwise going into engineering, etc for the better pay & opportunities.
Another problem with this claim is that we've seen it used disingenuously far too many times by corporations trying to claim that there aren't enough programmers in the US - when they're obviously just trying to put a PR spin on their outsourcing.
my first was a 360/50:
- cardpunch for a UI.
- code reuse was actually card deck reuse
- if you were fast and lucky you *might* get four program runs a day
- desk-checking your code was critical - there were no debuggers
- 512k of memory - required that cobol compiler was unloaded before running cobol programs
- probably 20 to 40 different tape and disk units
- wrote code to be fast rather than easy to maintain
it was a good experience, but python & linux are so much more fun than cobol on a mainframe!
> Don't want to be harsh, but I happen to work with plenty people that have the same kind of reasoning as you gave, adding complexity,
> questions and red herrings to escape making decisions or proposing concrete solutions.
The problem with your approach:
> if previous_value > 10000 and current_value > previous_value*10 then
> ask for validation by authority
> endif
> The '10000' and the '10' should be in the static data of the application.
is that it is an arbitrary static threshold - based on gut reaction and probably never to be updated. It'll either be so high that it is almost never used, or so low that it generates tons of false positives. This is why a statistical approach is far better - just compare the increase in value to the increase in value of all the other homes. If > 3std then trigger your exception action.
Of course, if you can get the user to accept a deviant workflow to handle these approvals, then fine. In my experience the realization that you need this often happens late in a project, and they won't want to make any changes at this point. That's why I'd recommend a data quality approach instead, which is easier to add on (again, in my experience).
> Well, I happen to think that a rule that said "No property can get an increase of 800000% in value in a year" would have catched that problem...
sure, but what about 100%? 30%? 2000%? Where do you draw that line *exactly*?
> Why wouldn't a financial management/accounting system have similar rules enforced and monitored?
I think the issue is that most people seek to address data validation problems through simple business rules such as "no property can be over $20,000,000 in value"
- in which you know that sooner or later this rule will become obsolete
or they try to add additional workflow steps such as "any property worth over $10,000,000 must be validated by supervisor prior to be added to property rolls"
- in which people disagree about workflow, the extra complexity & cost usually cause it to be killed
Personally, I prefer for data like this to keep a separate data quality attribute that gets flagged due to certain checks - and not necessarily boolean logic either - something like - if the value of this property is three standard deviations over all other property values then flag it as abnormal. Now, anything flagged as abnormal should then cause additional flags to trip so that it's easy to draw people's attention to this problem.
Then again, hell - there's also the use of extremely simple trending reports - which should have made this obvious. Didn't anyone get a little curious about this county having its total property value increase an average of 2% every year for 50 years then increase 10% (or five times the historical average) in a single year? Just guessing at the numbers here, but come on - it should have been glaringly obvious to anyone responsible for finances in the city. And that's without using this application at all.
> rest assured that Apple planners were well informed of this when they made the decision to switch
Not necessarily: IBM is a vast bureacracy and the left hand often has no idea what the right hand is doing. Additionally, this method may have been recently pushed ahead suddenly after some recent successes.
>>Both postgresql and mysql lack query parallelism,
> Wrong. Most query work is done in parallel, hardware permitting. Queries cannot be run on multiple CPUs at once (at present),
> which is what you're referring to, but that's very deceiving. CPUs are generally not the bottleneck, in databases it usually has a lot more to do with RAM and disk.
When referring to query parallelism I'm talking about it in the same context that you'd use on db2, oracle, informix, teradata, sql server, and probably sysbase: having the database engine split the query into parts and run them simultaneously to take advantage of multiple CPUs.
And in my experience (on db2, oracle, informix) this leads to linear performance improvements - at least up to 4 CPUs. This is the difference between 60 second tablescans and 15 second tablescans - a huge difference.
> [PostgreSQL lacks] any kind of partitioning,
> Wrong. Have you seen version 8.1 with constraint exclusion? It's been out for a while now.
I've used the same methods with oracle, db2, and sql server. I'd definitely use it if I was using postgresql today, but in my experience every implementation has been a pain in the butt to use.
> Where's the evidence?
don't look at me - there's no TPCs for postgresql
> If you put PostgreSQL on nice hardware with RAID and perhaps replication, just like Oracle, I would expect the results
> to be fairly mixed and inconclusive. Some things Oracle would win, some thing PostgreSQL.
I'm sure you're right - there must be some combinations of hardware and application domain in which postgresql would come out on top. There certainly are combinations of application domain, business size, budget, availability requirements, data volumes, and team skillsets - in which postgresql comes out on top.
> I'm sure there are problem domains where PostgreSQL just won't fit and Oracle will, but I don't think you acurately
> characterized those domains.
The domain I mentioned above (reporting, data warehousing, business intelligence, data mining) is one that I've got fifteen years of experience with. I'm sure I'll eventually be using postgresql for this as well, but think there's little value in fooling ourselves about how honest oracle sales staff is, how fun to work with ibm is, or how well suited to large data postgesql is.
> As far as SAP they released MaxDB which is what they base SAP on. MaxDB and MySQL are very closely related.
in what way? If I'm not mistaken MaxDB is the renamed SAPDB which is the renamed Adabas - an old crufy pre-relational database from the early 80s. I remember thinking it was obnoxious around 1985.
> Guess which database hasn't had any issue (at least that I know of) MSSQL. Kind of opposite of what you would expect huh?
Not really: mysql's normal behavior is to silently truncate, silently convert, silently ignore problems. It will often happily chug along through invalid calculations that other servers would stop immediately at.
And it is far easier to administer. Oracle used to be a real bear to design and administer for, though that's changed substantially over time - especially with 10g. In the old days if you didn't have the right skills available you could get in very bad trouble with oracle. It's still true, but to a much lesser extent. Part of the reason is the extreme configurability: you can tweak almost everything. With mysql you can tweak very little in comparison - and often memory pools that should be joined are actually separated (wasting valuable memory). But it's simple.
But I wouldn't put my critical business apps on mysql - even if it is simpler to admin. The designers showed a careless disregard for data quality. They've cleaned it up some, but not completely.
> OLAP would be better served by "lighter" databases, not OLTP.
;-).
What gives you that impression?
Consider that (R)OLAP doesn't benefit much from btree indexes - which are ineffectual for selectivity of greater than 2% of your data. That is, if you want to analyze 100% of the data for a single month in a database with 12 months of data @ 1,000,000 rows per month - a btree index won't be useful in just selecting one month of data. Partitioning will be useful - but you're only going to get that from db2 or oracle (or on sql server's immature implementation at ~$30k/cpu now). Light databases won't support it. Right off the bat you just took a 12x performance penalty by going with the lightweight product.
And when postgresql/mysql scan that 12,000,000 rows - they're doing it single-threaded. Even if you're on a four-way server. Whereas db2 or oracle can parallelize that query - giving almost a linear performance improvement. That's another 4x performance penalty you took by going with a lightweight product.
In other words, db2 or oracle would have been about 48x the speed of postgresql or oracle in this common olap scenario. And that doesn't even get to optimizer maturity (will bury mysql), memory tuning, OLAP functionality, materialized views, etc, etc, etc.
Some day the lightweight products will get there. Of course they won't be so lightweight when they do
> Actually, unofficially of course (thanks to Oracle's license), PostgreSQL is well known for beating Oracle in many small to
> medium size databases. Feel free to ask around. It's not hard to find people that performed their own shootouts of PostgreSQL
> vs Oracle and picked PostgreSQL because the performance was equal or better at a fraction of the cost.
In my experience this usually occurs because it takes more expertise to tune oracle than mysql, postgresql, or sql server. But this isn't to say that Postgresql isn't fine for many applications - the performance that oracle/db2/etc offers isn't always necessary.
> Simple fact is, parallel queries are not going to save you anything on simplistic queries...etc..etc...
Actually, I find that in many applications being developed today it is no longer adequate to merely rehost an app from one technology to another. It has become necessary to deliver some analytical components within even simple applications. For example, in a typical simple transactional application now you may log everything that occurs (ten years ago you never would have done that), and provide totals, running averages, etc to show data broken out over time by category, etc. This isn't rocket science, but requires a great optimizer, query parallelism, and partitioning to run quickly.
> You'll find many people that contribute to PostgreSQL by actually picking another DB...and the developers are fine with that.
yep, postgresql has a great community
> If IBM cannot find the generosity to release a 'free' version of a defunct operating system
OS/2 is rumoured to use third-party software licensed by IBM from Microsoft - that they can't open source. How does this make them "not generous"?
> The DB2 free version is probably some sort of scheme for getting lock-in to the platform and is not just an example of generosity by IBM.
Lock-in? Well, getting mindshare at least. Which puts them in the same company as:
- sql server (free extremely limited database version)
- oracle (free extremely limited database version)
- mysql (free vaguely-defined database version)
The only database products that I'm aware of that don't do this are Postgresql and Firebird. Neither of which match db2 for performance. And nor did this free version of db2 just suddenly appear - they had a very low-cost version for a few years.