Comparing MySQL and PostgreSQL 2 902
Mr. Jax writes "6 years ago Mr Poet submitted the story Comparing MySQL and PostgreSQL. Since then both databases have evolved to wherever they are today.
Are the points raised 6 years ago still valid? What has changed? Are there other things to consider since then (e.g. licensing)?" This is certainly a valid question since both databases have had to evolve with the times. Have these applications been specialized to fit a particular niche market or are they both still strong competitors? What does the horizon look like for the development of these programs, especially considering the recent MySQL partnership with SCO?
Get off it ScuttleMonkey (Score:4, Insightful)
Yawn.... (Score:3, Insightful)
Another question (Score:5, Insightful)
Re:Popularity (Score:5, Insightful)
I don't really know what to say about all of this - these incompatibilities are really frustrating as an end-user of this software, but I understand that it's hard to make things work with both MySQL and PostgreSQL, and resources are limited. What frustrates me is that these incompatibilities create a form of lock-in - once you've based your app on MySQL, you are stuck with it.
I suspect that if you were to start now, and to use the SQL spec rather than the MySQL documentation as a reference while doing your development, you would wind up with something that was a lot more portable, so this isn't actually an argument against using MySQL. It's more an argument towards sticking to standards when using whatever db you choose, so that when the time comes to use a different DB backend, you aren't faced with a monumental refactoring job.
Re:popularity (Score:4, Insightful)
That's probably because those features are part of PostgreSQL and is the main argument for why people believe that PostgreSQL is overtaking MySQL. Also the fact the PostgreSQL can run PL/SQL with only some modifications, and visa-versa.
I used to like MySQL (Score:5, Insightful)
MySQL was good enough, and all the stuff that hardened DBAs said to me - "It doesn't do transactions", or "It handles NULLs wierdly", etc, just didn't apply.
But when I tried to do a query like this: SELECT * FROM foo where bar NOT IN (SELECT blib from wheee) - MySQL advised me that it "didn't do" "NOT IN" queries. I tried to work around it, but after trying all the JOINs I could, it just didn't seem like something that I could get round. (I wasted quite a long time trying to work around this, and although I'm sure that some really top DBAs out there can do it, I couldn't.)
So, mysqldump > mysql.dump, and then restore into Postgres.
I've never looked back. MySQL is now just coming to fill in all the gaps it's missing - but just go with Postgres. It's rather good.
No mention of SQL servers can go without the Gotchas: Mysql [sql-info.de] and Postgres [sql-info.de]. The worst MySQL is probably that it modifies data as you insert it without throwing an error. Yuk.
Re:Another question (Score:5, Insightful)
Then arrange to have the benchmarking done in a country which won't uphold anti-competitive bullshit clauses (and when Oracle protest that the license lets them sue the guy in the jurisdiction of Buttfuck, Illinois, will tell them where they can stick their extradition request).
Although I reckon such a case (brought by Oracle) might still get thrown out in a US court, I wouldn't bet my life savings on that, and the US legal system means you're unlikely to get fees paid if Oracle lose (does this *ever* happen in the US?); a great way for the large company to effectively win by attrition if the benchmarkers don't have that much money.
Re:Popularity (Score:4, Insightful)
It's not like there is a HUGE difference, as long as no dbms specific procedural language was used (think plsql (oracle)) it's pretty trivial to port an application from one dbms to the other
The biggest differences are usually pretty subtile and indeed rather frustrating, but by no means hard to solve.
The biggest and most 'incompatible' difference between postgres and mysql is the autoincrement field really, the rest is just small fish to fix.
Not exactly ... (Score:4, Insightful)
If I get a site license from Microsoft, that's something else.
If Bill Gates and I do a press release about our new partnership, that's an entirely different thing.
SCO and MySQL AB did the press release thing. That's not the same as SCO buying a license to distribute.
Web Tools (Score:3, Insightful)
If there's a better web interface for Postgres than phpPgAdmin, let me know so I can try it.
Re:Another question (Score:2, Insightful)
Mysql is very isp friendly (Score:5, Insightful)
For a mom and pop ISP with only 3 or 4 employees this is significant. Is it feature filled? No
Its just included in the default user account which is difficult if not impossible with posgresql unless you manually install it for each account.
Users on the web dont need something heavy unless they are a commercial website. Also there are a ton of php and perl scripts and tools for users to use.
This is why msql is so popular. Its what ISP's prefer.
Re:Not exactly ... (Score:4, Insightful)
I could do a press release about how I just bought a tube of toothpaste at the local Kroger. The wire service(s) would happily take my money and put the story on their distribution network(s). Big whoop.
Re:My point of view (Score:3, Insightful)
To be fair, Oracle targets the really high-end apps or performance where hiring a dedicated Oracle expert(s) is worth it.
I doubt even Postgre can match the performance, reliability, and scalability of Oracle. Only IBM DB2 can come close so far. Postre may compete with Sybase and SQL-Server's level.
Thus, you are comparing apples to oranges.
Although for read-only speed, some RDBMS do seem faster than Oracle. Oracle seems optimized for a fairly even mix of reads and writes and reliability. Thus, if you sacrafice one of these, you perhaps may find something a bit faster (or at least easier to tune for such.)
(And please find a better name for Postgre. I keep thinking "post nasal green drip" when I see the name.)
Message bearer (Score:5, Insightful)
Considering you are nobody your press release wont really mean much. And I would also go so far as to say The SCO Group are nobody as well and their press releases don't mean much.
However, if Kroger made a big deal about your toothpaste purchase in the news section of their website it may actual be something to consider.
When SCO made their press release I didn't pay much attention because I have become very skeptical of any messages that come out of their organization. But it is disconcerting when MySQL considers the partnership to be news worthy as well:
http://www.mysql.com/news-and-events/news/article
burnin
Re:Mysql is very isp friendly (Score:3, Insightful)
However if your a small isp with little to no support staff mysql is the easiest to install and configure for average home users and small business on a server farm. That is all I am saying and why mysql is incredibly popular. Its just what the ISP's love using and including by default.
The same reason Windows and Dos became popular. Its the OS OEM's love to include.
It really doesn't matter. (Score:3, Insightful)
Issues like speed, resource usage, sql features, etc really don't matter very much as for 99% of db applications it just makes no difference at all and for the 1% it does then you'd better hire someone that knows the differences in dbs without having to look it up on Slashdot.
Most of the time it is better just to use the basics. I see people doing EVERYTHING in the db. Stored procedures, adding 1 + 1, massice complicated joins that'd be easy to do in anything other than SQL, etc. A big mistake. The db is the single hardest portion of your application server to replicate and load balance (even with the db supporting things like clustering). It's better to write your glue code in a normal language and just abstract that glue code as a sepperate service and use the db just for storing and retrieving data.
Re:Get off it ScuttleMonkey (Score:5, Insightful)
Well, MySQL AB is a for-profit company, they sell things to people. And, last time I looked into it, SCO wasn't gassing people or mowing down rain forrest, or something. Sure, they are obnoxious, but the truth is, so are many commercial companies we deal with every day.
But does it even matter? The jokes on SCO, they paid to use something in a product very few companies will buy.
More fun than dragging out this, would be guessing what non-issue Slashdot will toss up on their front page next in an attempt to stir shit and boost their dieing readership?
I must disagree. (Score:3, Insightful)
In other words, you're not actually running an enterprise-scale software system (which would require significant $$$, professional DBAs, and tools no matter WHAT database product you're using). You're running a single-man shop.
This is a great troll -- all of your points are sufficiently broad as to be impossible to prove or disprove either way. They're all obvious personal opinions but phrased as facts. Who's to say that any arbitrary enterprise software system can be satisfied with MySQL's features, or another's isn't? Or that you find MySQL's administration tools better than Oracle's (which I find to be therichest out there). Or that any "gotchas" you've had with BLOBs and CLOBs seem purely anecdotal.
The number of features that Oracle has over MySQL is simply staggering, as is its ability to robustly handle enormous concurrent loads. Its clustering support, backup & recovery abilities, and query optimizer are second-to-none. I'm glad you've found a cheap and better alternative, but I hardly think it's applicable to all.
Re:Another question (Score:5, Insightful)
My experience leads me to beleive the following things:
1) MS-SQL is a high quality database that is ridiculously easy to set up, tune, and maintain. It is also very expensive.
2) Postgres is a high quality database that is ridiculously easy to set up and maintain, but fairly difficult to tune. However, its performance is just as good as SQL server as long as you stay away from nested loops(*). It is also fairly inexpensive (free license, but increased TCO).
3) Oracle is a pig, and it requires a professional, certified swineherd. If you spend an amazing amount of money on licenses, gear, and certified DBAs you will presumably get good performance; I however was never able to get it past 60% of the performance of MS-SQL or Postgres.
(*) Nested loops are like candy to SQL server, and I've heard this is the same for Sybase (understandably). Deep sets of nested loops will kick the other databases I've tested in the teeth. Given an instruction with several nested loops and 16 million rows of data, I got results from SQL server in 5 minutes, results from Oracle 9 in an hour, and results from Postgres in 18 hours. This was a year ago and Postgres has changed, so it might be better now. Does MySQL handle them well?
Re:Get off it ScuttleMonkey (Score:2, Insightful)
That's true, there are a lot of obnoxious commercial companies, but SCO has actually surpassed just being obnoxious. Their business model actually includes getting revenue from suing or threatening to sue their customers. That's way beyond what other obnoxious companies do. I'm not saying other companies have never sued a customer, I'm saying that SCO is doing this to extort money from their customers and also from people who don't even use SCO products (like linux users.)
The SCOboys putrid conduct doesn't stop there. Just read over their press releases over the last couple of years and you'll find them so full of lies, contradiction, and deceit you will be amazed. Really. SCO is in a whole class of their own.
So, in this case, it does matter that MySQL has partnered in this manner with SCO. It says to me that MySQL might not be mowing down the rainforest, but they're willing to sell the mowers to the ones who are.
Re:Popularity (Score:3, Insightful)
I hate to burst your bubble, but the differences have nothing to do with a poorly designed spec. They have everything to do with companies either being too lazy, or too stubborn to adjust to and adhere to the specs. Even M$, who created the ODBC standard fails to adhere 100% to it in both Access and MS SQL.
In their defense however, DBMS's have often evolved far faster than the specs could keep up resulting in dozens of different ways to do something the specs didn't originally cover. However, my forgiveness ends right where the spec catches up and then the dbms developers fail to add compatibility to their product. The fear that compatibility will leave room open for customers to migrate to a competing product is exactly why the USA is about 2 to 3 years behind in technology right now. Go to NTT Docomo's website and look at their newest line of phones and you will note two very distinct trends:
#1 The lowest model blows away all US phones.
#2 They all share the same baseline standard design...which forces them to compete in the non-standard areas...which rewards the consumer with a consistant design and interface and innovation.
Wake me up when companies (or even OSS project managers) in the US stop screwing their customers with proprietary interfaces designed to lock in their customer base. I really don't measure a product's worth by the number of users it has....otherwise I'd still be using IE.
Just compared MySQL 4.0.12 vs PG 8.0.3 (Score:5, Insightful)
Anyways, PostgreSQL IMHO has some things going for it:
- More features like triggers, stored procs, schemas, subselects, etc then the current stable version of MySQL supports. About the only thing I find myself using are subselects which are just a nice to have.
- Attempts to be "safer" with your data via WAL, etc. Good for unreliable environments.
- Tends to follow the SQL standards closer then MySQL
- Is BSD licenced so you don't have to worry about licensing issues.
- #postgresql on freenode is great. The people there are intelligent, knowledgeable and friendly if you're not an *sshole. They've helped me a lot.
The problems I have with PostgreSQL is that:
- INSERT is very slow (about 3x slower compared to MySQL/InnoDB) for my dataset. The "answer" is to use the COPY command or disable your indexes/FK's which is f*cking lame since you loose all your relational integrity. I was willing to trade off performance for disaster prevention (system crash, power failure, etc) by disabling WAL, but you can't actually do that.
- The OSS tools available aren't as good for postgres as they are for MySQL. I've yet to find anything as nice or complete as phpmyadmin for Pg or something that supports schema's for ER Diagrams. Frankly, I'm sick and tired of designing my DB in vim.
- Having to run vacuum all the time to help the query optimizer figure things out. Why this doesn't happen automagically in the background without me having to worry about it is beyond me.
- In general, I find the documentation on mysql.com superior to on postgresql.org, but #postgresql more then makes up for it.
Frankly, all the technical "problems" in MySQL or Pg can be worked around if you're willing to think out side of the box.
Re:Another question (Score:3, Insightful)
(secretly posting this to lure someone into refuting/solving my problem)
Re:Haw haw (Score:5, Insightful)
Yes, I do. That's why I set the length in the first place. If I wanted to truncate the data, I'd tell the DB to do that.
if you REALLY need the logic to reject things like blank inputs in web forms then you should be doing that in your application logic anyway
This is the problem with MySQL's cheerleaders - they believe that the app designer should re-invent the wheel, rather than expecting the DB to do the stuff that it's supposed to do.
Why on earth should I have to write extra code to check each input field, when I should just be able to send the results to the DB, and return the error message to the client if it fails?
just trying to relay the idea that in the context that mysql is usually used, these small quirks don't have a large impact.
The only reason that people believe that they don't have a large impact is because they don't actually understand the *reasons* for the correct behaviour. The attitude is "well, I'm a programmer, so I'll just program around the problems", rather than expecting the DB to handle it (like it's supposed to.)
Re:Another question (Score:2, Insightful)
I'm normally MS fan but MS SQL is an very good (if expensive) tool (but then, they didn't write it, but that's another story).
Escuse any typos, I'm drunk...
Re:MySQL vs. Oracle (Score:3, Insightful)
Because a project you download is hard-coded to it. (Mambo, some BBSes, eCommerce sites, etc.) I like PgSQL better than MySQL, but I keep having to use MySQL for the PHP projects I play with.
Re:Friendster (Score:3, Insightful)
On second thought, who knows? Maybe it used to. That would explain the constant downtime and speed problems.
Re:Haw haw (Score:4, Insightful)
That is exactly the MySQL attitude. The problem is that my data tend to be important, or I wouldn't be putting them in a RDBMS. I'd rather the database assume the usual, safe thing - data should not silently truncated. If I want to throw away my data, I'll do it explicitly.
And filling in NOT NULLS is also handy for the same reason.... if you REALLY need the logic to reject things like blank inputs in web forms then you should be doing that in your application logic anyway....
What I REALLY need is for the database to pay attention to the constraints I specify. If I didn't care if these fields were blank, I wouldn't have said "NOT NULL".
I am by no means sticking up for non-conformity... just trying to relay the idea that in the context that mysql is usually used, these small quirks don't have a large impact.
That is not the context in which mysql.com is claiming their database is usually used. They claim they have a real database.
Re:popularity (Score:2, Insightful)
The DBMS is not validating the user's input. That is the application's job. The DBMS is validating that the data an application is trying to store conforms to the schema. The DBMS is your last hope of having correct data. Your application could be blowing chunks all over the place. As long as the data is correct, then the problem can be fixed.
In a small web environment this distinction is harder to see. There is usually only one version of the client application in existence. In a larger system you can't always trust the application. Servers in a large server farm may have slightly different versions (e.g. if updates are applied in stages to avoid crashing the entire system because something was missed in testing). Different applications sharing the data (e.g. common data but different needs: sales and management). You might also have a "thick" client application the versions of which are often very difficult to control. If one in-use version validates incorrectly then you can't trust the data anymore, even if the majority of in-use versions are correct.
Re:Popularity (Score:2, Insightful)
While it may not be the best design, SQL *is* the abstraction layer of choice for using an RDBMS. As written it's weird, inconsistent, potentially unparseable and arguably incomplete, but that doesn't mean it's inefficient (arguments about whether NULL values should be allowed notwithstanding).
I've written SQL for MySQL, Informix (IDS & SE), Postgresql and Oracle. Supporting all of them at once is essentially impossible (on date handling alone), but using the 'right kind of quotes', standard SQL syntax and type names for simple scalars and so on makes the differences minimal in most areas.
The remainder of the differences range from substantial missing features (stored procedures, foreign keys, triggers) which might rule a specific DBMS out for a given design, and stupid misfeatures which most databases have in some measure (I'll give Oracle a guernsey for 'select
I've been in the position of taking code originally written for Informix or MySQL and having to port it to PostgresQL or Oracle, and the more standard it looked the easier it was. Why port it if it was working fine? Well, *we* had more than one customer; try telling them that they should install MySQL alongside their Oracle server...
You refer to built-in functions, different syntax, different data types etc.: SQL provides a standard library of SQL functions, and most good DBMSes allow you to define your own in SQL, C or Java, as well as 'private' languages like PlSQL and PlPgSQL; differing syntax should have no impact on how efficient a query is; and while the standard SQL types are limited, they are sufficient for a wide range of applications, and where there's a genuine need the major players have responded with very similar features (e.g., int8 and 'serial' types) that map well onto each other.
If you care, and your RDBMS supports views and stored procedures, then there's an excellent chance that you can provide a clean, efficient (within the limits of the DBMS) and consistent interface across a number of RDBMS's; it may take more time than writing a straight-to-MySQL (or whatever) app might, but it will be more portable and maintainable (and for complex apps, it may reduce your coding time in any event).
huiac at internode.on.net
Re:Another question (Score:3, Insightful)
- Complex column & table constraints;
- Rapid retrieval of rows satisfying particular conditions, by indexing on a complex expression;
- Programmable actions on insert/update/delete (triggers)
- Updateable views
huiac at internode.on.net
PostgreSQL SCO "relationship" (Score:5, Insightful)
MySQL has only one commercial vendor, who helpfully call themselves MySQL AB, so even Slashdot readers can understand what they sell. So SCO made a deal with them to compile and test a certified MySQL binary for SCO.
PostgreSQL has had a number of failed commercial vendors over the years, but one current one is EnterpriseDB. Maybe not having the word PostgreSQL in the company name confused slashdot readers who think Walmart sell Wals?
eWeek report [eweek.com] it as the same deal. "SCO has added open source database vendors MySQL and EnterpriseDB to its partner list, said SCO President and CEO Darl McBride"
What is the difference?
Oh, I forgot. This is slashdot where MySQL is evil because they charge for some things and where we all sit around and pretend that MySQL does not have transactions and that PostgreSQL vacuum is a good thing.
Yay for Postgres/Perl. Boo for MySQL/PHP. Can I have mod points now?
Re:It really doesn't matter. (Score:4, Insightful)
And go ahead, tell my that having corupt data doesn't matter. Then I'll throw sarbanes-oxley at you and laugh.
Re:popularity (Score:2, Insightful)
It's true that MySQL does not have syntax for object-oriented queries. The object-relational model is significantly different from the relational model; there are a lot of applications where it's not needed.
I guess neither Postgres nor MySQL supports native storage of XML. However, it might not be too hard to implement. 6 years ago, neither database could store GIS data; today, they both can.
Re:Another question (Score:5, Insightful)
The best approach IMO is somewhere in the middle. I think both extremes are boneheaded.
Your RDBMS is there to do three things:
1) Store data
2) Maintain data (i.e. triggers, check constraints, etc)
3) Present your data (views, possible some stored procedures, etc).
I generally try to avoid programming directly against stored procedures. If necessary, I will write a view and update rules/triggers (depending on the RDBMS) to make this appear like a table.
In general your data model logic should be entirely contained within and enforced by the database (Date's Central Rule). This does not mean that application function should be a stored procedure. Far from it. Instead, by doing things this way, you can do a fair bit of heavy lifting in the RDBMS where appropriate, and have your application logic in the application where it belongs.
For example, sending email from the database backend is not really the best solution to any problem I am aware of in large part because this would happen outside of transactional control. Instead, use a trigger to place an item in a queue that an external program can use to send it. This way if your transaction rolls back after the email is sent....
People on both extremes simply don't understand the features and limitations of the transactional and relational models.
Re:PostgreSQL SCO "relationship" (Score:3, Insightful)
Well, anyone who glances at my posting history will know that I'm not exactly a fan of the PostgreSQL community (although the technology is looking good in 8.1). However, I'd prefer to dislike PostgreSQL for legitimate reasons, so let's clear up that press release that you linked to. It mentions the company, EnterpriseDB, and says they "make the PostgreSQL database." However, the PostgreSQL fans here on Slashdot have pointed out that EnterpriseDB is just one of a few companies that offer commercial branches of PostgreSQL. EnterpriseDB supposedly doesn't own it, control it, or speak for it. They are separate entities. The PostgreSQL developers apparently want to distance themselves from this, which I think is the correct move. In fact, I think they should be doing it more loudly. At least enough so that I don't have to. :)
If PostgreSQL really does distance itself from EnterpriseDB and SCO, then yes, yay for them. But if you want, we can still dislike them for other reasons. As for MySQL, I think they really have made a blunder here. In fact, they've made two. They made the mistake of bragging about their deal with the devil in a press release, and then stuck with it as people began to voice concerns. So yeah, boo on MySQL.
Of course, despite the booing, I'm still hoping MySQL will do a 180 degree turnaround on this. Their community -- both employees and users -- is very friendly and productive. The communities that have sprung up around other database products are typically missing one of the two (friendly but not productive, or productive but not friendly).
Re:Another question (Score:3, Insightful)
I've never been entirely convinced by item three. Views are occasionally useful, but if you have a user interface that allows ad-hoc queries, they may be the only way to enforce data security. But if you're writing apps you may as well code the query directly. You'll need to change the code if the view changes, but apart from a few ultra-generic table based apps, that is always going to be true.
Far from it. Instead, by doing things this way, you can do a fair bit of heavy lifting in the RDBMS where appropriate, and have your application logic in the application where it belongs.
I'd agree with that. I'll occasionally break the rule for pragmatic reasons and I don't always make best use of constraints and their ilk, but I have to agree with the sentiment.
Instead, use a trigger to place an item in a queue that an external program can use to send it. This way if your transaction rolls back after the email is sent.... ;-)
Unless I'm misunderstading you, that cannot happen. Assuming your emailer is a little app that sits on top of the mail queue table and periodically issues "select * from...", then it never sees the queued message, because it doesn't de-cloak until the transaction commits. I think that was your point.
The best approach IMO is somewhere in the middle. I think both extremes are boneheaded.
The boneheadedness I meant lies in using programmng languages developed by database vendors. They're almost always awful.
For one thing, they tend to hold the database as being more important than the language, so you get languages where the only iteration is using cursor selects for example.
Then there is the "everything has to look like SQL and/or PL/I" syndrome, which sees table definition syntax being reused to specify parameter passing.
Finally there is the "SQL is a static, descriptive language, therefore our coding langauge must work the same way" disease, which gives us langauges with all the frustrations of coding in lisp or prolog, but without the cool stuff which makes those languages fun.
Anyway, enough with the rant. Bit of a hobbyhorse of mine, as you may have guessed :)
Re:Another question (Score:5, Insightful)
I have to agree with grassbeetle above.
Software architecture-wise:
- You can't make a scalable architecture if you put everything in one single place (in this case the database).
- You will be hard-pressed to create a failure tolerant architecture if you stuff everything in a single point of failure.
- Databases are NOT application servers. They are designed with data storage and retrieval in mind, not reliable execution of complex business logic. Amongst other things databases do not make available in an easy and/or reliable way some of the standard application server functionality.
- All external components of the application (for example UIs) have to connect to the database. You're now stuck to using the connection protocols from the chosen database. This might cause all sort of problems with security, firewalls, use of asychronous messaging, availability of adaptors in the platform you are deploying your applications to, etc...
- Spliting your application accross several servers or in a multi-tiered geographical distribution is much harder.
- All coders have to have a good knowledge on how to work with the specific database you are using.
- Programing inside databases is not standartized. Different databases and indeed different versions of the same database have sometimes different versions of the same language or different libraries available. The language/libraries have not been so throughly used/tested/examined by a big user comunity (while for example standard C/Java/etc libraries have been thouroughly debugged in billions of man-hours of use). This means more library bugs and a lack of third party tools for software design and development inside the database.
- Facilities such as version control, source control, etc are either not available or difficult to use in a reliable manner.
- Availability of compatible 3rd party libraries or application modules is very, very restricted by comparison to NOT having your server side logic all inside the database.
- Forget about moving databases in the future. Also, simple migrating to a newer version of the database can be a nightmare.
Software design-wise, the design of the software will be strongly constrained by the internal structure of the database:
- Information flows will mostly have to be database-like information flows
- A true object oriented structure is pretty much impossible. At the most you can do weakly connected islands with an objecte oriented structure. If the database language you have to use is procedural forget about OO design.
- Server-side initiated connections to outside entities, thread control, ditributed transactions and other more advanced functionalities are pretty much impossible.
- Usage/integration with 3rd party libraries or application modules is very hard or even impossible.
Software programming-wise, and from my experience (mostly Oracle):
- The language sucks.
- The application libraries (not the DBA ones) suck big time.
Simply put, a software architect that puts all server-side logic inside the database is with this single choice removing almost all his other architecture options and creating/fortifying vendor lock-in of the application to the database itself and 3rd party tools and also of the development team itself by means of the knowledge experience they have/will gain with said database and said 3rd party tools.
Such a person should IMHO either be demoted to a place were he/she can't cause any damage or fired outright.
Re:MySQL vs. Oracle (Score:2, Insightful)
Thanks for the laugh!
Re:popularity (Score:3, Insightful)
Easy, it's centralized and easy to manage. This is the same reason that anyone uses a large robust server to begin with.
It is far easier to lock down one database than n+1 applications and ad hoc query users. Abstraction and modularization is good. This is computer science.
Re:Another question (Score:3, Insightful)
For example in PostgreSQL, you have to define update/insert/delete rules. Sometimes these can be tricky ...
mmm... that's what I mean. If the views get too complex then maintaining them may become more expensive than writing a comparatively simple interface app. Views appear to offer a generic plug-in solution, but as you say, it isn't always that simple.
I think the problem is that updatable views are a kludge. They don't work in terms of the relational model, and that's why they throw up such problems. I think they are fundamentally the wrong approach, but I'm realist enough to use them if they save me a lot of work. But it'd have to be a fairly specialised set of circumstances...