> BTW, PostgreSQL 8.1 will have much more useful table partitioning, and there is a project (Bizgress) > aimed at adding parallelism across nodes in business intelligence environments (we had this discussion > before once on Slashdot;-) )
Yep, i remember.
It's very cool seeing postgresql pick up some of these capabilities. It is really becoming a very cool database. DB2 and Oracle will still have an edge for five years I think, but beyond that I think that they are in deep trouble.
I mostly make my living with db2 these days, oracle/informix/sybase/sql server in the past. But I'll gladly start working with postgresql once the BI functionality is in place. But spending any time with mysql's glaring deficiencies in data quality, BI performance, etc in the face of the marketing hype seems too much like y2k work. Yuck.
Regarding memory:
- I haven't tuned oracle memory in forever, but it sounds like you're trying to use 8 gbytes of memory
on a 32-bit cpu. In that case oracle and db2 are both limited to 1-3.2 gbytes of memory depending
on the os. There are ways of getting around that limitation but they are os-specific. On 64-bit
CPUs, everything is very simple.
- btw, putting most of your memory into a single buffer pool is seldom the best way to manage your
memory: ideally you would create a few sets of buffer pools for different types of tables. That's
the best way to increase your cache hits: indexes and all small tables pretty much just live in
memory at that point.
Regarding Innodb:
- very fast? compared to what? writing to myisam? well, sure, but that's about it.
- keep in mind that at a few million rows and several million queries, you shouldn't have
a problem with this data in any database. This is small. Unless of course your queries
are complex, are frequently reading 50,000 rows then aggregating that data into trends,
counts, etc. Of course, if you are - then oracle's parallel query and partitioning will
deliver great performance - possibly *dozens* of times faster than what mysql can do.
Triggers:
- as long as you keep it simple they are wonderful and are still easy to port. You can with
triggers:
- auto-populate some columns that the application doesn't require, but might be useful in
partitioning the data (assuming your database supports partitioning).
- populate denormalized tables strictly for reporting or searching
- populate history tables with changes to all data in various important tables
- capture changes in order to copy data to another database
- etc
- yes, you could do many of these things from within the application. but it'll be harder. Why
make life hard?
- and sometimes you *can't* do these things from within the app - it's closed source, but luckily
for you it's on a database that supports triggers.
Stored Procedures
- again, keep it simple and they are very useful and not at all difficult to port between databases
- when validation is performed here it allows you to *easily* enable multiple applications
to write to the database. I'm working on a project right now in which I've got to allow another
department to create a portal to one of our databases. The folks in this department can barely
write SQL, and I'm not interested in them training on our dime. We're giving them stored
procedures that they won't be able to screw up. Much, much safer this way!
- also gives your dba the ability to change the physical database (adjust for changes in business,
performance, security, etc) without having to change all the applications: the change can be
encapsulated.
- and sometimes you *can't* do these things from within the app - it's closed source, but luckily
for you it's on a database that supports triggers.
Views
- again, this gives you a ton of flexibility
- for example: in most of my databases I don't give de
> Yes, mostly mainframes, but I've no doubt that some industries were running > "enterprise" apps 5 years ago on platforms that aren't as robust as MySQL5 > is now.
Ah, good question. Here's how to look at this:
1. mysql is just now in v5 putting in pieces that most commercial products had 10-20 years ago:
- views (been around since something like 1981 in db2 & oracle)
- triggers (been around since around 1995)
- subselects (been around in db2/oracle since 1981 or so, in mysql for what? 1 year?)
- transactions (been around in db2/oracle since around 1981, in mysql via innodb for 2 years)
- online backups (been around 10 years? mysql still requires a separate product)
- stored procs (been around 10 years? mysql just getting to it)
2. data quality - mysql has:
- silent errors
- silent data truncations & conversions
3. standardization - mysql has:
- quite a few deviations from ansi sql - everything from comments to weird create statements
- historically the lack of views, transactions, stored procs, triggers, and poor join performance meant that many queries had to be completely rewritten for mysql
4. performance
- mysql's performance reputation was built upon easily-cached data that could be easily looked up using simple indexes on mysql. Its performance of large queries (select many/most rows) stank, and its write performance was horrible - since required table locking.
- mysql's performance on innodb was better for mixed environments, but innodb has a bloat problem that can get serious.
- no support for query parallelism, partitioning, etc - isn't 1/40th the speed of a commercial product for many queries.
- mysql's optimizer is trivial - and can't be relied upon for complex queries (> 5 tables)
No, you can live without row locking - as long as you've got at least page-level locking. It's the accumulation of all the other stuff that makes you want to run from it.
Well - I can agree with you that i've got concerns about XP:
- poor use of patterns
- poor use of easily reusable code
- poor use of technical domain knowledge (everything is reinvented with each project)
- poor consideration of long-range architecture issues
- absolute dependency on skilled staff
But in spite of the above, I've seen XP projects be far more successful than RUP projects. Sure, they may need massive refactoring 1-2 years later. But at least they reached production - and provided value for that time. The RUP projects on the other hand tend to be so expensive and ineffective (poor usability, poor adaptability, etc) that they're often cancelled early on due to cost or hated by the users later on.
So, in balance and in spite of its flaws I'd give a huge vote to XP. Then I'd seek to mitigate some of its risks with a few minor modifications.
> RUP is in the Agile category of develpment processes
got to disagree here
RUP is heavy as hell, it's just that since XP took off at the same time the RUP folks have tried to make RUP do it all. So, sometimes they'll tell you that it can encompass agile methodologies - even though their iterations have so much overhead they really are more like waterfall phases than agile iterations.
Anhow, the way it pans out is that you typically end up with is a $100k consultant bill as well as months of work to chop all the useless artifacts out of the framework to be agile.
Then you'll still end up with mostly model-driven process with artificial roles and hand-offs. About that time you'll be seriously wondering why you left the agile path!
I think it's really a dead-end - there are quite a few folks exploring completely new methods for working together - that actually seem to work. And these methods don't look anything like RUP.
> I'm part of the enterprise change control staff at my company, and I can tell you that the more tightly > we implement controls, the more often we discover that the problems that arise are from developers > implementing untested changes without authorization. If you force them to submit change documents, and > don't let the changes get into the code base until the change has been authorized (for that matter, don't > let them code until the change has been authorized), then have someone else test the changed software > before the code gets pushed up, you've got a three-legged stool to stand on, and you have an auditable > process that maintains accountability.
don't forget "The Law of Unintended Consequences" which shows that: 1. as accountability goes up attitude, morale, productivity, and efficiency go down 2. once you hit critical mass on paperwork, process, etc you destroy motivation - there's some point on the curve at which point everyone just says 'who cares' and 'why bother' 3. it's impossible to really anticipate everything upfront, which means that minor changes that in a system and organization that embraces agility & resilence can be easily handled in stride take 40x as long in an organization afraid of blame. 4. most of the work is done by the motivated and talented 10% of the staff. these people leave rather than put up with the bureacracy designed to hinder the 90% that are unproductive.
RUP is a disaster, I've seen it absolutely wreck companies.
> Could this be one of the reasons behind recent comments regarding MySQL wanting to be the Ikea of databases and not wanting to compete with Oracle?
Anyhow, it wouldn't surprise me - oracle's acquisition of innodb doesn't bode well for mysql:
- larry ellison (CEO of Oracle) is a megalomaniac and a nut-case to boot
- even though mysql is a poor competitor of oracle, it still has "mindshare" - and some
people will undoubtably send their cash mysql's way.
- oracle doesn't really need this code
- mysql might have gotten a warning, and hoped to avert this fate
So, why would oracle be buying this product - unless they wanted to harm mysql? The only scenario I can imagine that would benefit mysql users is if oracle next buys mysql - and is using this as a ploy to maneuver mysql into a negotiating corner.
Of course, even if oracle did buy out mysql, I'm not seeing that as anything good for mysql users: oracle has a lot of skill obviously, but they've also got a ton of bureacracy.
ok, add to the list of reasons for why you should own your own io layers: it prevents your competitors from buying them out from under you!
> not having benchmarked them, i would guess that sql server would be faster on the same hardware. > rofl. > Not having voted, or watched television, I would guess that Hilary Clinton won the last election.
and not having benchmarked a corvette vs a festiva I'd still bet on the corvette in the 1/4 mile.
you could play it safe, and assume they are both equal until you've spent a few days or even weeks exhaustively testing them. but at the end of the day, this is only a smart move if you know nothing about automobiles, just climbed out from under a rock, or whatever.
> Sabre according to the MySQL site: "estimated a 40% TCO savings when budgeting for the $100 million > project. In many cases, the ongoing TCO savings are expected to be up to 80% - twice what was estimated".
Yeah, but keep in mind that a case study from technical staff in the trenches almost always looks different than a case study from senior management: in which case the motivation is always political. This is why you never heard senior managers admitting mistakes in these "case studies": they're simply propaganda. Often the TCO includes the benefits of a new system - which every vendor involved tries to reinterpret as savings caused by their involvement.
This isn't much different than case studies in which linux turned out to be far cheaper than solaris, etc. But it turned out that they compared nothing besides the cost of hardware and software: the actual labor costs actually increased costs rather than reduced them (since more servers were required).
> My own background is for a little place which is now serving about one in every thousand web pages > viewed in Alexa's sample; and with some database servers down still showed billion query per day > capability on a handful of MySQL database servers. About 3,500 pages per second (bad Slashdotting is > about 600 pages per second). A few hundred gigabytes of compressed data, in the terrabyte range > without.
Sounds great. Still not even nearly record-breaking: db2's most recent benchmark was for 3 million *transactions* per minute. And that's on a single database that won't have any problems with data synchronization or bizarre problems with data quality.
The fact that a load-balanced array of mysql servers can provide substantial read-mostly content is great - and has some interesting applications. Of course, you could plug *any* database into the same architecture with similar success. And of course, it has its own limitations: i recently looked at doing this for a massive reporting environment - but it was too much of a pain to keep all server 100% in synch. Plus, the scalability wasn't as good as if I just spread the data across the individual nodes beowulf-fashion - which is built-into db2.
> The worlds in the process of changing and those who want to keep up need to be moving fast.
yep, and they need to know more than just what a single vendor has to say - whether that vendor is microsoft, oracle, or mysql; and they also need to know what the best practices are for their technology - not just the favored vendor work-arounds of the day.
i think the cause of this split has more to do with the rest of the world getting increasingly dissolutioned and pissed with the us than with any specific internet-management issue.
so we've ignored most of the what the world thinks is right and are hell-bent on doing everything our own way. Well, fine - just that we shouldn't be surprised when the rest of the world ceases to cooperate with us.
> As for me, I'm happy that in spite of taking minutes, it's giving me the > correct answer. That's all I need and I don't think it's fair to directly > compare MySQL to a $20,000 database. Of course it won't perform as good. > It's like comparing a Toyota to a Ferrari and complaining that the Toyota > won't go as fast.
Sure - if it only takes a few minutes every now and then that might not be a big deal.
But regarding the cost of the alternatives:
- postgresql is freer (no way of having to face $600/year charges as with mysql), and has a better optimizer.
- oracle is only around $1-2k for a small footprint database. this wouldn't
include partitioning, but at least you'd get a smarter optimizer.
- db2 is around $700 for a 2-way server. this would provide partitioning
(via mdc or union-all views), parallelism, and a better optimizer.
- sqllite is freer (again, no cost), and I suspect has a better optimizer.
So, for $700 once, plus maintenance (18%/year?) you'd have a vastly faster product than MySQL - which can cost you $600/year. And you don't need to talk to a lawyer to figure out whether or not you need to pay for mysql. Or you could get other products that are faster with complex queries and are completely free.
I've read the article, am familiar with the product, and am also familiar with data warehousing. This is just propaganda.
> MySQL has a demonstrated capacity for managing very large databases. Mytrix, > Inc. maintains an extensive collection of Internet statistics in a one > terabyte (1 TB) data warehouse that contains 20 billion rows of data.
MySQL is a horrible product for warehousing: no query parallelism, no partitioning, primitive memory management, primitive optimizer, etc, etc. 20 Billion rows in a single table? What would mysql do with that? Any typical warehousing queries would take hours to come back. More likely either the database owners are just logging data someplace cheap, or they are creating hundreds of much smaller tables.
> It replicates 10-60 gigabytes per day from its master database to a MySQL server farm.
Ah, a 'server farm'. So, the 20 billion rows are probably spread across dozens of mysql servers. This explains it all. Even SQL Server can do better than that.
> The MySQL databases are used to support a shopping application that can accommodate a million fare changes per day.
Yeah, I think db2's most recent benchmark was for something like 3 million transactions a minute.
This is little more than an advertisement for mysql. A little poking around would probably show that he's on the mysql payroll.
> There is a decent sized market out there where organizations don't need a > complicated schema or fancy features.
then they might want to check out sqllite: a simple and completely free database *without* bizarre integrity problems.
> They just want to do your average query on a fairly large db, but do it fast, > hella fast. They'd rather put MySQL on a fast proprietory filesystem. Stripe > and load balance off some fast storage arrays. And just blast away.
if they're blasting away with mysql, then they aren't doing much with the data:
- no parallel query capability
- no memory tuning
- no partitioning
- no optimizer sophistication
In short, unless you've got extremely simple queries looking up small sets of rows - mysql is slow as a pig, and can't compete with the commercial products. Again, if you *know* what you're doing.
And assuming that you're interested in data integrity and are using the innodb database, then postgresql is just as fast. Possibly *much* faster if you're writing moderately complex queries with 5 or more tables.
The idea that mysql is fast is a myth that came from php kids playing with a database for the first time. Once you actually compare the products available today mysql has nothing going for it - except quite a lot of inexperienced fans. Which, I have to admit, is probably worth quite a bit.
> Yeah, Postgres doesn't currently support this. IMHO it isn't that useful -- > the performance improvement I'd expect would be pretty small (for one thing, > all Postgres buffering is done in addition to the kernel's buffering, so the > net impact will be smaller). It also adds a significant administrative burden > -- you need to configure which objects go in which pools, as well as how large > each pool is.
this can be extremely useful - when you've got a very busy transactional database - the key to good performance is getting that high buffer hit ratio. You'll often have a few very large tables that are too big to cache - with a variety of small tables as well. Using this approach allows you to easily ensure that the larger tables don't force the smaller ones out of the cache. And it isn't much overhead - since (in db2) you'd typically only create a few buffer pools for these few different table types. Then assign at the tablespace level anyway.
>... assuming your table scan is CPU-bound, which is almost certainly not the > case. In practice, intra-query parallelism is useful for two scenarios that I > can think of: creating large indexes, and OLAP workloads in which you are > running a small number of concurrent queries, each of which is extremely > expensive. In more normal OLTP circumstances, the number of concurrent clients > far exceeds the number of CPUs in the box, so you don't need to parallelize > within each query. Still, I agree this would be useful to have in some > circumstances, although it's a bit difficult to see how to implement it > reasonably.
I've found that with db2 (8.2) on a well-balanced system it results in a linear performance improvement up to 4 cpus (and maybe beyond, haven't tested). This is most useful in olap applications, but even in normal OLTP apps you've got the occasional tablescans, massive backups, index creations, etc to deal with.
> PostgreSQL 8.1 (currently in beta) includes "constraint exclusion", which is > essentially a primitive form of table partitioning (using inheritence and > check constraints, you divide the data into tables with distinct check > constraints; the optimizer has been improved to recognize when a child table > can be omitted from the query plan by looking at the check constraints > involved).
That's cool. In db2 these are called 'informational constraints' - and can be used to support writable union-all views for this type of range partitioning. This is a pretty cheap method of range partitioning (can get a little messy with a thousand daily partitions, etc), but if it works well there's nothing wrong with it.
> Theory is good and all, but benchmarks will provide a much nicer comparison. > Microsoft has been saying for years how much better their technology is, > but the stats show a completely different perspective. > So, yeah, I'd like to see a thorough comparison of DB2, Oracle, MySQL and > PostgreSQL, and MSSQL if you must.
Well, you could take a look at www.tpc.org - to see how the vendors have configured their databases in various situations, how fast the results were, and how much the config cost. Last I looked SQL Server is very competitive at the low end of data volumes & transaction rates for price.
Postgresql and mysql aren't there yet, but i'm sure they will be before too long. In the meanwhile, without stats, if you understand the technology it isn't that difficult to figure out basic performance issues.
Without stats, but with an understanding of how these products partition data - it is still fairly staight-forward to get a basic idea of what kind of performance to expect.
For example, it's easy to see why MSSQL can be competitive at 100 gbytes, but completely falls behind beyond that. And of course, you'd expect the same from mysql and postgresql. Beyond 100 gbytes db2, oracle, and informix are roughly comparable. beyond about 5 terabytes db2 takes the lead. This is all driven by database partitioning and parallelism: you really don't need to benchmark them to anticipate these results.
> And 7.1 is even less relevent to this discussion.
Nope: as of this spring there were still rediculous issues with python quoting and newlines.
This will hopefully be fixed - since using python as a stored procedure language within postgresql is hard to beat.
Re:PostgreSQL vs MSSQL vs Oracle
on
Sun Eyes PostgreSQL
·
· Score: 2, Interesting
> I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability
that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000. A perfect example was stored procedures - where you couldn't return a result list in postgresql, and the python stored procedure language required so many ticks and escapes it was impossible to use.
Regarding oracle, it used to be so much worse than it is today. For small databases it really doesn't take much time at all IF you are familiar with the product. If not, then you need to hit the books for a little bit. And the price isn't hefty at all - it can be cheaper than your redhat license for small databases. The much larger databases is where the cost is really at, but postgresql doesn't compete there anyway. In the middle ground - that's where you've got decisions to make - and the cost could go either direction, depending on how you architect the solution & negotiate.
Regarding yukon - the informal benchmarks i've seen indicate that it isn't going to provide anything for performance. Another major drawback with SQLServer is the entire gui orientation: it's great for demos and development databases, but if you've ever had to migrate code (such as for DTS) from test to production by recreating then you know what i'm talking about.
I'd also consider db2 & informix: together have a huge chunk of the market and are gradually merging together. The licensing is about 1/2 that of oracle, with about 98% of the functionality. Plus they'll handle more data. On the downside there are considerably fewer admin tools for db2 than oracle, and fewer talented developers or dbas as well. Ah, and perhaps the biggest issue: there's no Larry Ellison involved.:-)
> Actually that's not remotely true. We're not talking about MySQL here. > PostgreSQL is quickly gaining all the "high-end" features of Oracle: > tablespaces, failover, replication, etc. In some cases, they aren't yet as > fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly > coming into its own.
Hmmm, as much as I like postgresql I don't see it that way:
1. replication? it's most often used as a clunky way of implementing failover - yuck. In my large data architectures, replication is almost never used: it's almost always the worst solution to some problem.
2. tablespaces? yep, they're good things to have. that's fine - i think oracle and db2 have supported them for around twenty years, so it's hardly high-end technology tho.
3. failover? ok, this is critical - but there are also many different forms & flavors. I'm not familiar with what postgresql has so I won't comment - other than to say it needs to be rock-solid.
ok, how about a few more:
4. memory management: a high-end database should give you a ton of control over how memory is handled - especially when you plan to buy tons of it. Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces. These bufferpools (caches) are how to easily ensure that hits against some tables or indexes occur 99% of the time from memory, and others 50% because they're so much larger. I'm pretty sure that neither postgresql or mysql can do this.
5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.
6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.
7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to. So, while db2 or oracle are scanning 10% of the data - postgresql or mysql still have to scan 100% of the data. That would result in a 10x increase in speed over postgresql or mysql.
that's just off the top of my head - given a little time this list would double.
Postgresql is a fine tool, and it has all the technology that db2 or oracle had 12-15 years ago. And that's a cool achievement, and qualifies it do a ton of cool projects. Plus, with time it will catch up. But it still has a *long* way to go.
> Someone I know is working with an MS SQL Server database that's too slow to be usable
Not true, sql server is a fine database. Its problems have more to do with being excessively gui-driven, expensive compared to OS dbms, and owned by microsoft than anything about the speed.
> and I'm wondering whether I should suggest they go with PostgreSQL instead
not having benchmarked them, i would guess that sql server would be faster on the same hardware.
> Do you still need to VACUUM your databases?
I think an automated vaccuum has been created. But it was never a real issue in my opinion anyway - basically the existance of vacuum enables postgresql to speed deletions and updates - since some table maintenance can be performed asynchronously. So, cron (or task schedule) the thing to run nightly and you're fine.
> Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)?
Not yet, but it's getting there. 5.0 should be a big improvement, but it still has a long way to go - not necessarily implementing the essential feature set, but now making those implementations robust.
> How does Oracle's performance compare to the rest?
Depends on what you need to do: have a small database, or a medium-sized database that's purely transactional? The open source databases can do the job. But if you've got a large database, or want to do some analytics (like show simple trends of data) then oracle/db2/informix are your friend. These commercial databases can easily be 40x the speed of postgresql or mysql on the same hardware for analytical queries.
> Have you conducted tests yourself or are you merely repeating fanboi retoric? > I've used both views and subqueries with MySQL recently. stored procedures are > listed for V5.
Views are listed as a new feature in 5 - which is just a development release. So, yes - the original poster was correct on that account.
MySQL picked up sqlqueries in V4.1, though I haven't checked to see how well they implemented them: ie, can you:
- select (select max(date) from a)
- select blah from table (select blah,blah,blah from a,b where...)
- select blah from a where a.blah in (select blah from b)
- select blah from a where a.blah in (select blah from b where b.foo = a.foo) And can it perform these subselects without tanking performance? Especially given their poor quality optimizer and notorious performance problems with queries of 5+ tables...
So, given the massive gulf between just doing something and doing it well, and mysql's history of shooting for the bare minimum the actual usefulness of their stored procedures, views, and subqueries will take time to determine.
I'm running large data warehouses on db2 on aix. I could run this on linux (power5 hardware supports linux, so does db2).
But why the hurry? In the meanwhile, the upfront cost is the same, aix has a lower tco (fewer patches to install, more reliable, etc). The hardware cost for power5 isn't that much more than for intel (when you're talking about seriously fast hardware). All the same apps and utilities run on aix (python, gnu stuff, etc).
Aren't you in the same spot? Why rush large oracle 12-way servers to linux? It'll happen eventually.
I think an even more compelling situation is one in which you max out your 2CPU or 4CPU box: and have no where to go for extra cycles/bandwidth/etc.
In a lpar situation you can still easily provide the extra resources - with a more traditional server configuration you'll have to rehost. Which will completely waste the cost of your prior server, plus you've got to pay for a larger one as well - which may only be maxed out once a month. Then there's the labor, outage, and risk involved in the migration - which can easily exceed the cost of the hardware itself.
I've got a p570 sitting in a data center waiting for its install right now. I'm going to be using AIX 5.3 and DB2 8.2.
Linux would be fine, but there's no price advantage, and aix is more mature. But dynamic memory isn't the real issue there - most of the memory will be consumed by the database - so it's db2's ability to dynamically change memory footprint that is the more critical.
> While I completely agree with the spirit of your message, the reality is there > needs to be some agreed-upon contract. What would you subsitute, since code > won't help (as evidence of agreement) in a court case.
Personally, I avoid fixed-price contracts - unless the functionality is extremely straight-forward, well-understood and simple.
Time & Materials contracts allow me to deliver a series of prototypes that refine my and my client's requirements far better than a contract. Plus, I don't have to constantly worry about meeting the letter of a contract that may be known to be obsolete, and don't have to push back on changes - just due to the overhead of changing the contract.
Of course, it's not really this easy - since so many customers insist on fixed price. I'm not talking from experience here, but I wonder if there are lost opportunities to break large projects into much smaller pieces - with separate requirements/contracts. This wouldn't eliminate the spec, but would break it into smaller/more managable pieces.
Some of the problems with specs is that management doesn't understand that these massive waterfall projects that spew specs just don't work: they think requirements can be gathered up front, and so they negotiate and agree to waterfall projects that use this approach. Sigh, then after years of projects that have failed I guess they must have a variety of excuses?
- project a: development team wasn't skilled enough
- project b: customer couldn't make up their mind on what they wanted
- project c: development team wasn't CMM level2
- project d: customer kept changing their requirements
- project e: development team wasn't CMM level3
- project f: development team wasn't using.net/j2ee
- project g: customer kept changing their requirements
- project h: development team wasn't using struts/etc
- project g: customer kept changing their requirements
- project h: development team wasn't using web services
at the end of the day these managers don't have any referencable customers. They might have avoided court, but may go out of business any way.
Slashdot Mirror
> BTW, PostgreSQL 8.1 will have much more useful table partitioning, and there is a project (Bizgress) ;-) )
> aimed at adding parallelism across nodes in business intelligence environments (we had this discussion
> before once on Slashdot
Yep, i remember.
It's very cool seeing postgresql pick up some of these capabilities. It is really becoming a very cool database. DB2 and Oracle will still have an edge for five years I think, but beyond that I think that they are in deep trouble.
I mostly make my living with db2 these days, oracle/informix/sybase/sql server in the past. But I'll gladly start working with postgresql once the BI functionality is in place. But spending any time with mysql's glaring deficiencies in data quality, BI performance, etc in the face of the marketing hype seems too much like y2k work. Yuck.
Regarding memory:
- I haven't tuned oracle memory in forever, but it sounds like you're trying to use 8 gbytes of memory
on a 32-bit cpu. In that case oracle and db2 are both limited to 1-3.2 gbytes of memory depending
on the os. There are ways of getting around that limitation but they are os-specific. On 64-bit
CPUs, everything is very simple.
- btw, putting most of your memory into a single buffer pool is seldom the best way to manage your
memory: ideally you would create a few sets of buffer pools for different types of tables. That's
the best way to increase your cache hits: indexes and all small tables pretty much just live in
memory at that point.
Regarding Innodb:
- very fast? compared to what? writing to myisam? well, sure, but that's about it.
- keep in mind that at a few million rows and several million queries, you shouldn't have
a problem with this data in any database. This is small. Unless of course your queries
are complex, are frequently reading 50,000 rows then aggregating that data into trends,
counts, etc. Of course, if you are - then oracle's parallel query and partitioning will
deliver great performance - possibly *dozens* of times faster than what mysql can do.
Triggers:
- as long as you keep it simple they are wonderful and are still easy to port. You can with
triggers:
- auto-populate some columns that the application doesn't require, but might be useful in
partitioning the data (assuming your database supports partitioning).
- populate denormalized tables strictly for reporting or searching
- populate history tables with changes to all data in various important tables
- capture changes in order to copy data to another database
- etc
- yes, you could do many of these things from within the application. but it'll be harder. Why
make life hard?
- and sometimes you *can't* do these things from within the app - it's closed source, but luckily
for you it's on a database that supports triggers.
Stored Procedures
- again, keep it simple and they are very useful and not at all difficult to port between databases
- when validation is performed here it allows you to *easily* enable multiple applications
to write to the database. I'm working on a project right now in which I've got to allow another
department to create a portal to one of our databases. The folks in this department can barely
write SQL, and I'm not interested in them training on our dime. We're giving them stored
procedures that they won't be able to screw up. Much, much safer this way!
- also gives your dba the ability to change the physical database (adjust for changes in business,
performance, security, etc) without having to change all the applications: the change can be
encapsulated.
- and sometimes you *can't* do these things from within the app - it's closed source, but luckily
for you it's on a database that supports triggers.
Views
- again, this gives you a ton of flexibility
- for example: in most of my databases I don't give de
> Yes, mostly mainframes, but I've no doubt that some industries were running
> "enterprise" apps 5 years ago on platforms that aren't as robust as MySQL5
> is now.
Ah, good question. Here's how to look at this:
1. mysql is just now in v5 putting in pieces that most commercial products had 10-20 years ago:
- views (been around since something like 1981 in db2 & oracle)
- triggers (been around since around 1995)
- subselects (been around in db2/oracle since 1981 or so, in mysql for what? 1 year?)
- transactions (been around in db2/oracle since around 1981, in mysql via innodb for 2 years)
- online backups (been around 10 years? mysql still requires a separate product)
- stored procs (been around 10 years? mysql just getting to it)
2. data quality - mysql has:
- silent errors
- silent data truncations & conversions
3. standardization - mysql has:
- quite a few deviations from ansi sql - everything from comments to weird create statements
- historically the lack of views, transactions, stored procs, triggers, and poor join performance meant that many queries had to be completely rewritten for mysql
4. performance
- mysql's performance reputation was built upon easily-cached data that could be easily looked up using simple indexes on mysql. Its performance of large queries (select many/most rows) stank, and its write performance was horrible - since required table locking.
- mysql's performance on innodb was better for mixed environments, but innodb has a bloat problem that can get serious.
- no support for query parallelism, partitioning, etc - isn't 1/40th the speed of a commercial product for many queries.
- mysql's optimizer is trivial - and can't be relied upon for complex queries (> 5 tables)
No, you can live without row locking - as long as you've got at least page-level locking. It's the accumulation of all the other stuff that makes you want to run from it.
Well - I can agree with you that i've got concerns about XP:
- poor use of patterns
- poor use of easily reusable code
- poor use of technical domain knowledge (everything is reinvented with each project)
- poor consideration of long-range architecture issues
- absolute dependency on skilled staff
But in spite of the above, I've seen XP projects be far more successful than RUP projects. Sure, they may need massive refactoring 1-2 years later. But at least they reached production - and provided value for that time. The RUP projects on the other hand tend to be so expensive and ineffective (poor usability, poor adaptability, etc) that they're often cancelled early on due to cost or hated by the users later on.
So, in balance and in spite of its flaws I'd give a huge vote to XP. Then I'd seek to mitigate some of its risks with a few minor modifications.
> RUP is in the Agile category of develpment processes
got to disagree here
RUP is heavy as hell, it's just that since XP took off at the same time the RUP folks have tried to make RUP do it all. So, sometimes they'll tell you that it can encompass agile methodologies - even though their iterations have so much overhead they really are more like waterfall phases than agile iterations.
Anhow, the way it pans out is that you typically end up with is a $100k consultant bill as well as months of work to chop all the useless artifacts out of the framework to be agile.
Then you'll still end up with mostly model-driven process with artificial roles and hand-offs. About that time you'll be seriously wondering why you left the agile path!
I think it's really a dead-end - there are quite a few folks exploring completely new methods for working together - that actually seem to work. And these methods don't look anything like RUP.
> I'm part of the enterprise change control staff at my company, and I can tell you that the more tightly
> we implement controls, the more often we discover that the problems that arise are from developers
> implementing untested changes without authorization. If you force them to submit change documents, and
> don't let the changes get into the code base until the change has been authorized (for that matter, don't
> let them code until the change has been authorized), then have someone else test the changed software
> before the code gets pushed up, you've got a three-legged stool to stand on, and you have an auditable
> process that maintains accountability.
don't forget "The Law of Unintended Consequences" which shows that:
1. as accountability goes up attitude, morale, productivity, and efficiency go down
2. once you hit critical mass on paperwork, process, etc you destroy motivation - there's some point on the curve at which point everyone just says 'who cares' and 'why bother'
3. it's impossible to really anticipate everything upfront, which means that minor changes that in a system and organization that embraces agility & resilence can be easily handled in stride take 40x as long in an organization afraid of blame.
4. most of the work is done by the motivated and talented 10% of the staff. these people leave rather than put up with the bureacracy designed to hinder the 90% that are unproductive.
RUP is a disaster, I've seen it absolutely wreck companies.
Mysql could replace its transactional foundation (innodb) with postgresql.
This would give it a transactional foundation that oracle couldn't buy out from under them!
> Could this be one of the reasons behind recent comments regarding MySQL wanting to be the Ikea of databases and not wanting to compete with Oracle?
Anyhow, it wouldn't surprise me - oracle's acquisition of innodb doesn't bode well for mysql:
- larry ellison (CEO of Oracle) is a megalomaniac and a nut-case to boot
- even though mysql is a poor competitor of oracle, it still has "mindshare" - and some
people will undoubtably send their cash mysql's way.
- oracle doesn't really need this code
- mysql might have gotten a warning, and hoped to avert this fate
So, why would oracle be buying this product - unless they wanted to harm mysql? The only scenario I can imagine that would benefit mysql users is if oracle next buys mysql - and is using this as a ploy to maneuver mysql into a negotiating corner.
Of course, even if oracle did buy out mysql, I'm not seeing that as anything good for mysql users: oracle has a lot of skill obviously, but they've also got a ton of bureacracy.
ok, add to the list of reasons for why you should own your own io layers: it prevents your competitors from buying them out from under you!
> not having benchmarked them, i would guess that sql server would be faster on the same hardware.
> rofl.
> Not having voted, or watched television, I would guess that Hilary Clinton won the last election.
and not having benchmarked a corvette vs a festiva I'd still bet on the corvette in the 1/4 mile.
you could play it safe, and assume they are both equal until you've spent a few days or even weeks exhaustively testing them. but at the end of the day, this is only a smart move if you know nothing about automobiles, just climbed out from under a rock, or whatever.
> Sabre according to the MySQL site: "estimated a 40% TCO savings when budgeting for the $100 million
> project. In many cases, the ongoing TCO savings are expected to be up to 80% - twice what was estimated".
Yeah, but keep in mind that a case study from technical staff in the trenches almost always looks different than a case study from senior management: in which case the motivation is always political. This is why you never heard senior managers admitting mistakes in these "case studies": they're simply propaganda. Often the TCO includes the benefits of a new system - which every vendor involved tries to reinterpret as savings caused by their involvement.
This isn't much different than case studies in which linux turned out to be far cheaper than solaris, etc. But it turned out that they compared nothing besides the cost of hardware and software: the actual labor costs actually increased costs rather than reduced them (since more servers were required).
> My own background is for a little place which is now serving about one in every thousand web pages
> viewed in Alexa's sample; and with some database servers down still showed billion query per day
> capability on a handful of MySQL database servers. About 3,500 pages per second (bad Slashdotting is
> about 600 pages per second). A few hundred gigabytes of compressed data, in the terrabyte range
> without.
Sounds great. Still not even nearly record-breaking: db2's most recent benchmark was for 3 million *transactions* per minute. And that's on a single database that won't have any problems with data synchronization or bizarre problems with data quality.
The fact that a load-balanced array of mysql servers can provide substantial read-mostly content is great - and has some interesting applications. Of course, you could plug *any* database into the same architecture with similar success. And of course, it has its own limitations: i recently looked at doing this for a massive reporting environment - but it was too much of a pain to keep all server 100% in synch. Plus, the scalability wasn't as good as if I just spread the data across the individual nodes beowulf-fashion - which is built-into db2.
> The worlds in the process of changing and those who want to keep up need to be moving fast.
yep, and they need to know more than just what a single vendor has to say - whether that vendor is microsoft, oracle, or mysql; and they also need to know what the best practices are for their technology - not just the favored vendor work-arounds of the day.
i think the cause of this split has more to do with the rest of the world getting increasingly dissolutioned and pissed with the us than with any specific internet-management issue.
so we've ignored most of the what the world thinks is right and are hell-bent on doing everything our own way. Well, fine - just that we shouldn't be surprised when the rest of the world ceases to cooperate with us.
> As for me, I'm happy that in spite of taking minutes, it's giving me the
> correct answer. That's all I need and I don't think it's fair to directly
> compare MySQL to a $20,000 database. Of course it won't perform as good.
> It's like comparing a Toyota to a Ferrari and complaining that the Toyota
> won't go as fast.
Sure - if it only takes a few minutes every now and then that might not be a big deal.
But regarding the cost of the alternatives:
- postgresql is freer (no way of having to face $600/year charges as with mysql), and has a better optimizer.
- oracle is only around $1-2k for a small footprint database. this wouldn't
include partitioning, but at least you'd get a smarter optimizer.
- db2 is around $700 for a 2-way server. this would provide partitioning
(via mdc or union-all views), parallelism, and a better optimizer.
- sqllite is freer (again, no cost), and I suspect has a better optimizer.
So, for $700 once, plus maintenance (18%/year?) you'd have a vastly faster product than MySQL - which can cost you $600/year. And you don't need to talk to a lawyer to figure out whether or not you need to pay for mysql. Or you could get other products that are faster with complex queries and are completely free.
I've read the article, am familiar with the product, and am also familiar with data warehousing. This is just propaganda.
> MySQL has a demonstrated capacity for managing very large databases. Mytrix,
> Inc. maintains an extensive collection of Internet statistics in a one
> terabyte (1 TB) data warehouse that contains 20 billion rows of data.
MySQL is a horrible product for warehousing: no query parallelism, no partitioning, primitive memory management, primitive optimizer, etc, etc. 20 Billion rows in a single table? What would mysql do with that? Any typical warehousing queries would take hours to come back. More likely either the database owners are just logging data someplace cheap, or they are creating hundreds of much smaller tables.
> It replicates 10-60 gigabytes per day from its master database to a MySQL server farm.
Ah, a 'server farm'. So, the 20 billion rows are probably spread across dozens of mysql servers. This explains it all. Even SQL Server can do better than that.
> The MySQL databases are used to support a shopping application that can accommodate a million fare changes per day.
Yeah, I think db2's most recent benchmark was for something like 3 million transactions a minute.
This is little more than an advertisement for mysql. A little poking around would probably show that he's on the mysql payroll.
> There is a decent sized market out there where organizations don't need a
> complicated schema or fancy features.
then they might want to check out sqllite: a simple and completely free database *without* bizarre integrity problems.
> They just want to do your average query on a fairly large db, but do it fast,
> hella fast. They'd rather put MySQL on a fast proprietory filesystem. Stripe
> and load balance off some fast storage arrays. And just blast away.
if they're blasting away with mysql, then they aren't doing much with the data:
- no parallel query capability
- no memory tuning
- no partitioning
- no optimizer sophistication
In short, unless you've got extremely simple queries looking up small sets of rows - mysql is slow as a pig, and can't compete with the commercial products. Again, if you *know* what you're doing.
And assuming that you're interested in data integrity and are using the innodb database, then postgresql is just as fast. Possibly *much* faster if you're writing moderately complex queries with 5 or more tables.
The idea that mysql is fast is a myth that came from php kids playing with a database for the first time. Once you actually compare the products available today mysql has nothing going for it - except quite a lot of inexperienced fans. Which, I have to admit, is probably worth quite a bit.
> Yeah, Postgres doesn't currently support this. IMHO it isn't that useful --
... assuming your table scan is CPU-bound, which is almost certainly not the
> the performance improvement I'd expect would be pretty small (for one thing,
> all Postgres buffering is done in addition to the kernel's buffering, so the
> net impact will be smaller). It also adds a significant administrative burden
> -- you need to configure which objects go in which pools, as well as how large
> each pool is.
this can be extremely useful - when you've got a very busy transactional database - the key to good performance is getting that high buffer hit ratio. You'll often have a few very large tables that are too big to cache - with a variety of small tables as well. Using this approach allows you to easily ensure that the larger tables don't force the smaller ones out of the cache. And it isn't much overhead - since (in db2) you'd typically only create a few buffer pools for these few different table types. Then assign at the tablespace level anyway.
>
> case. In practice, intra-query parallelism is useful for two scenarios that I
> can think of: creating large indexes, and OLAP workloads in which you are
> running a small number of concurrent queries, each of which is extremely
> expensive. In more normal OLTP circumstances, the number of concurrent clients
> far exceeds the number of CPUs in the box, so you don't need to parallelize
> within each query. Still, I agree this would be useful to have in some
> circumstances, although it's a bit difficult to see how to implement it
> reasonably.
I've found that with db2 (8.2) on a well-balanced system it results in a linear performance improvement up to 4 cpus (and maybe beyond, haven't tested). This is most useful in olap applications, but even in normal OLTP apps you've got the occasional tablescans, massive backups, index creations, etc to deal with.
> PostgreSQL 8.1 (currently in beta) includes "constraint exclusion", which is
> essentially a primitive form of table partitioning (using inheritence and
> check constraints, you divide the data into tables with distinct check
> constraints; the optimizer has been improved to recognize when a child table
> can be omitted from the query plan by looking at the check constraints
> involved).
That's cool. In db2 these are called 'informational constraints' - and can be used to support writable union-all views for this type of range partitioning. This is a pretty cheap method of range partitioning (can get a little messy with a thousand daily partitions, etc), but if it works well there's nothing wrong with it.
> Theory is good and all, but benchmarks will provide a much nicer comparison.
> Microsoft has been saying for years how much better their technology is,
> but the stats show a completely different perspective.
> So, yeah, I'd like to see a thorough comparison of DB2, Oracle, MySQL and
> PostgreSQL, and MSSQL if you must.
Well, you could take a look at www.tpc.org - to see how the vendors have configured their databases in various situations, how fast the results were, and how much the config cost. Last I looked SQL Server is very competitive at the low end of data volumes & transaction rates for price.
Postgresql and mysql aren't there yet, but i'm sure they will be before too long. In the meanwhile, without stats, if you understand the technology it isn't that difficult to figure out basic performance issues.
Without stats, but with an understanding of how these products partition data - it is still fairly staight-forward to get a basic idea of what kind of performance to expect.
For example, it's easy to see why MSSQL can be competitive at 100 gbytes, but completely falls behind beyond that. And of course, you'd expect the same from mysql and postgresql. Beyond 100 gbytes db2, oracle, and informix are roughly comparable. beyond about 5 terabytes db2 takes the lead. This is all driven by database partitioning and parallelism: you really don't need to benchmark them to anticipate these results.
> And 7.1 is even less relevent to this discussion.
Nope: as of this spring there were still rediculous issues with python quoting and newlines.
This will hopefully be fixed - since using python as a stored procedure language within postgresql is hard to beat.
> I've come to the conclusion that PostgreSQL is clearly a step above MSSQL in terms of features and scalability
:-)
that might be true of v7.3 - when using postgresql 7.1 it was clearly not as easy to work with as MSSQL 2000. A perfect example was stored procedures - where you couldn't return a result list in postgresql, and the python stored procedure language required so many ticks and escapes it was impossible to use.
Regarding oracle, it used to be so much worse than it is today. For small databases it really doesn't take much time at all IF you are familiar with the product. If not, then you need to hit the books for a little bit. And the price isn't hefty at all - it can be cheaper than your redhat license for small databases. The much larger databases is where the cost is really at, but postgresql doesn't compete there anyway. In the middle ground - that's where you've got decisions to make - and the cost could go either direction, depending on how you architect the solution & negotiate.
Regarding yukon - the informal benchmarks i've seen indicate that it isn't going to provide anything for performance. Another major drawback with SQLServer is the entire gui orientation: it's great for demos and development databases, but if you've ever had to migrate code (such as for DTS) from test to production by recreating then you know what i'm talking about.
I'd also consider db2 & informix: together have a huge chunk of the market and are gradually merging together. The licensing is about 1/2 that of oracle, with about 98% of the functionality. Plus they'll handle more data. On the downside there are considerably fewer admin tools for db2 than oracle, and fewer talented developers or dbas as well. Ah, and perhaps the biggest issue: there's no Larry Ellison involved.
> Actually that's not remotely true. We're not talking about MySQL here.
> PostgreSQL is quickly gaining all the "high-end" features of Oracle:
> tablespaces, failover, replication, etc. In some cases, they aren't yet as
> fine-grained as Oracle. In other cases, they're superior. PostgreSQL is quickly
> coming into its own.
Hmmm, as much as I like postgresql I don't see it that way:
1. replication? it's most often used as a clunky way of implementing failover - yuck. In my large data architectures, replication is almost never used: it's almost always the worst solution to some problem.
2. tablespaces? yep, they're good things to have. that's fine - i think oracle and db2 have supported them for around twenty years, so it's hardly high-end technology tho.
3. failover? ok, this is critical - but there are also many different forms & flavors. I'm not familiar with what postgresql has so I won't comment - other than to say it needs to be rock-solid.
ok, how about a few more:
4. memory management: a high-end database should give you a ton of control over how memory is handled - especially when you plan to buy tons of it. Here the big databases allow you to assign different amounts of memory to different buffer pools, which are then assigned to different tablespaces. These bufferpools (caches) are how to easily ensure that hits against some tables or indexes occur 99% of the time from memory, and others 50% because they're so much larger. I'm pretty sure that neither postgresql or mysql can do this.
5. process management: in db2 your application writes to a buffer pool, an asychronous agent picks up that change and writes it to a log file, another asynchronous agent picks it up and writes it to the table. This heavily-asychronous behavior (and yes, with memory & processor tuning available for each agent type) allows you to maximize write-throughput. Postgresql and mysql are still in the slower sychronous world.
6. parallelism: in mysql and postgresql all queries are single-threaded. In db2 and oracle a large query will actually split itself up into multiple sub-queries to maximize throughput for multiple cpus and storage arrays. This provides db2 & oracle with linear performance improvements up to 4-8 cpus. In othe words, large queries that perform table scans can take advantage of SMP hardware for the commercial products - and cut down your query time by 75% on a 4-way compared to mysql and postgresql.
7. partitioning: btree indexes only work for very selective queries - like when you want 1% or less of the data of a table. But for many queries you need to crunch 5,10,or 15% of the data. That's where range partitioning comes in: you just scan the data you absolutely need to. So, while db2 or oracle are scanning 10% of the data - postgresql or mysql still have to scan 100% of the data. That would result in a 10x increase in speed over postgresql or mysql.
that's just off the top of my head - given a little time this list would double.
Postgresql is a fine tool, and it has all the technology that db2 or oracle had 12-15 years ago. And that's a cool achievement, and qualifies it do a ton of cool projects. Plus, with time it will catch up. But it still has a *long* way to go.
> Someone I know is working with an MS SQL Server database that's too slow to be usable
Not true, sql server is a fine database. Its problems have more to do with being excessively gui-driven, expensive compared to OS dbms, and owned by microsoft than anything about the speed.
> and I'm wondering whether I should suggest they go with PostgreSQL instead
not having benchmarked them, i would guess that sql server would be faster on the same hardware.
> Do you still need to VACUUM your databases?
I think an automated vaccuum has been created. But it was never a real issue in my opinion anyway - basically the existance of vacuum enables postgresql to speed deletions and updates - since some table maintenance can be performed asynchronously. So, cron (or task schedule) the thing to run nightly and you're fine.
> Has MySQL grown up yet (i.e. implemented the features it has been missing, compared to standard SQL)?
Not yet, but it's getting there. 5.0 should be a big improvement, but it still has a long way to go - not necessarily implementing the essential feature set, but now making those implementations robust.
> How does Oracle's performance compare to the rest?
Depends on what you need to do: have a small database, or a medium-sized database that's purely transactional? The open source databases can do the job. But if you've got a large database, or want to do some analytics (like show simple trends of data) then oracle/db2/informix are your friend. These commercial databases can easily be 40x the speed of postgresql or mysql on the same hardware for analytical queries.
> Have you conducted tests yourself or are you merely repeating fanboi retoric?
> I've used both views and subqueries with MySQL recently. stored procedures are
> listed for V5.
Views are listed as a new feature in 5 - which is just a development release. So, yes - the original poster was correct on that account.
MySQL picked up sqlqueries in V4.1, though I haven't checked to see how well they implemented them: ie, can you:
- select (select max(date) from a)
- select blah from table (select blah,blah,blah from a,b where...)
- select blah from a where a.blah in (select blah from b)
- select blah from a where a.blah in (select blah from b where b.foo = a.foo)
And can it perform these subselects without tanking performance? Especially given their poor quality optimizer and notorious performance problems with queries of 5+ tables...
So, given the massive gulf between just doing something and doing it well, and mysql's history of shooting for the bare minimum the actual usefulness of their stored procedures, views, and subqueries will take time to determine.
but...so what?
I'm running large data warehouses on db2 on aix. I could run this on linux (power5 hardware supports linux, so does db2).
But why the hurry? In the meanwhile, the upfront cost is the same, aix has a lower tco (fewer patches to install, more reliable, etc). The hardware cost for power5 isn't that much more than for intel (when you're talking about seriously fast hardware). All the same apps and utilities run on aix (python, gnu stuff, etc).
Aren't you in the same spot? Why rush large oracle 12-way servers to linux? It'll happen eventually.
I think an even more compelling situation is one in which you max out your 2CPU or 4CPU box: and have no where to go for extra cycles/bandwidth/etc.
In a lpar situation you can still easily provide the extra resources - with a more traditional server configuration you'll have to rehost. Which will completely waste the cost of your prior server, plus you've got to pay for a larger one as well - which may only be maxed out once a month. Then there's the labor, outage, and risk involved in the migration - which can easily exceed the cost of the hardware itself.
I've got a p570 sitting in a data center waiting for its install right now. I'm going to be using AIX 5.3 and DB2 8.2.
Linux would be fine, but there's no price advantage, and aix is more mature. But dynamic memory isn't the real issue there - most of the memory will be consumed by the database - so it's db2's ability to dynamically change memory footprint that is the more critical.
> While I completely agree with the spirit of your message, the reality is there
.net/j2ee
> needs to be some agreed-upon contract. What would you subsitute, since code
> won't help (as evidence of agreement) in a court case.
Personally, I avoid fixed-price contracts - unless the functionality is extremely straight-forward, well-understood and simple.
Time & Materials contracts allow me to deliver a series of prototypes that refine my and my client's requirements far better than a contract. Plus, I don't have to constantly worry about meeting the letter of a contract that may be known to be obsolete, and don't have to push back on changes - just due to the overhead of changing the contract.
Of course, it's not really this easy - since so many customers insist on fixed price. I'm not talking from experience here, but I wonder if there are lost opportunities to break large projects into much smaller pieces - with separate requirements/contracts. This wouldn't eliminate the spec, but would break it into smaller/more managable pieces.
Some of the problems with specs is that management doesn't understand that these massive waterfall projects that spew specs just don't work: they think requirements can be gathered up front, and so they negotiate and agree to waterfall projects that use this approach. Sigh, then after years of projects that have failed I guess they must have a variety of excuses?
- project a: development team wasn't skilled enough
- project b: customer couldn't make up their mind on what they wanted
- project c: development team wasn't CMM level2
- project d: customer kept changing their requirements
- project e: development team wasn't CMM level3
- project f: development team wasn't using
- project g: customer kept changing their requirements
- project h: development team wasn't using struts/etc
- project g: customer kept changing their requirements
- project h: development team wasn't using web services
at the end of the day these managers don't have any referencable customers. They might have avoided court, but may go out of business any way.