mysql is now my choice, after long time trying to make stuff functional in postgresql, the interest for postgresql is just to small, especially if you want to use addiotional modules :(
If one takes a bit of time to do the research, postgres works quite well. I have contributed some tidbits to drupal, and maybe one day they will be included, like:
Caching (this may get fixed in 4.7, but as it is, Postgres is a lousy choice for any site that gets more than a tiny amount of traffic, as it just doesn't scale well, though adding gobs and gobs of RAM may help)
Access control API (this forced me to completely abort a collaborative fiction project, which I'm still a little bitter about)
Organic groups
Currently buggy, but apparently functional:
Forums
Spam prevention
I have a site running under Postgres... but it took massive amounts of effort to get running and continues to be high maintenance every time I upgrade something. If you run Postgres and use external modules, or heavily stress your site, expect things to break. Don't try it if you don't have fairly good PHP and SQL skills so you can debug.
I run two mysql based drupal instances (one is civicspace distro), and one PostgreSQL. PostgreSQL being a prefered standard at my workplace.
The difference in the amount of time needed to successfully keep up to date with psql vs. mysql is significant. The upgrade of my PostgreSQL site to 4.5x took upwards of 30 hours, including several posts to module maintainers etc. Drupal MySQL upgrades often happen in terms of minutes. (Note: I am not a developer, nor a person with more than SysAdmin level database knowledge). I was unable to upgrade to 4.6x, so my site remains out of date.
I have been unable to resolve slow site response issues in a backport of the node_privacy_byrole module, which I find essential to running an workplace internet/intranet combined functionality site.
In the past I had worked with Adrian the former psql maintainer, who was quite helpful in resolving issues. But primarily the problem seemed to be a combination of the following:
Simply not enough Postgres users
Not enough user and maintainer resources to test and include patches
Module maintainers don't have Postgres available for testing (MySQl strict mode suggestion is excellent, as is education)
PostgreSQL users fixing things themselves, submitting reports, but not following back up, or not having readily available test environments to check final patch submissions (/me raises hand)
Lack of central knowledge base for PostgreSQL support
Lack of "review process & policy"? Perhaps contributed modules before being made available in the official download list could be run by the postgres maintainer?
Its difficult to stay active enough in the community to resolve these things. I find myself, even now, coming back to drupal.org considering whether to attempt an upgrade to 4.6.x again, wait for 4.7.x, or ask about the difficulty in switching from PostgreSQL to MySQL for that site. Which makes this poll and thread extremely timely.
I do think that a sign of Drupal's maturity would be to support multiple databases with equal proficiency. That requires, developer education, user participation, and an aggregated postgreSQL knowledge resource.
The only such central place for PostgreSQL stuff I have known about is:
Perhaps what Drupal needs most to improve Postgres support is to use its own collaboration engine to unify the postgres community. For me it is impossible to keep up with the amount of information on this site. I need a starting place.
The most positive thing that drupal postgres has going for it, is the fact that I have found many Postgres users to be SQL experts, offering sound advice and patches. The stuff is there to both educate module developers and support users.
Thanks to all who have worked so hard over the years inspite of the complaints.
What we should have akin to some other support ticketing applications is some more projects for database specific problems.
Like postgres, but I'm sure a few problems have also driven MySQL folks nuts.
If there was such a project for the Drupal core (the postgres problems for contributions get discussed in contributions), I'd most certainly participate.
With all due respect, why would you want to use PostgreSQL when MYsql is easier???
"if one takes a bit of time to do the research, postgres works quite well"
Why should we? Just because you like postgresSQL? Getting a site up and running and installing modules sometimes can take there toll and of course time. We don't have the time to do "a little research". You’re going to need a better reason to sell me on the idea.
PostgreSQL used to be better for SQL nuts because PostgreSQL supported SQL99 and MySQL had only SQL92.
MySQL was easier for PHP Web sites because:
* MySQL had autoincrement
* MySQL had choice of table types for better read performance.
* MySQL had PHPMyAdmin
Today MySQL 5 has about the same SQL as PostgreSQL. There is a PostgreSQL version of PHPMyAdmin. ADOdb lets you mix both databases in the one site and have your SQL automatically converted between the two.
If you want to write stored procedures then MySQL 5 lets you write stored procedures in SQL. I do not know if PostgreSQL has that or if you are still stuck with Perl.
Back when 95% of Web development was on Windows or NT based workstations, MySQL installed easily on both but PostgreSQL required Cygwin. For many years Cygwin was a real pig to install and use. Now that Linux has grown up to equal NT, Microsoft has downgraded NT to Windows, PostgreSQL has built an easier install system, and people are running twelve different operating systems under VM, You can have every table in a different database under different database software and build a system that spends 98.98 percent of the CPU time virtualising without actually retrieving data.
Me? I will stick with MySQL because I can use fast MyIsam tables for things that are mostly read and InnoDB tables when I need transactions.
I do enjoy replacing Oracle with PostgreSQL or MySQL. It is almost as much fun as replacing ASP with PHP.
If you want to write stored procedures then MySQL 5 lets you write stored procedures in SQL. I do not know if PostgreSQL has that or if you are still stuck with Perl.
Well, let's see... There's of course SQL and C... and PL/pgSQL, PL/Tcl, PL/Perl, PL/Python in the standard PostgreSQL distribution. There are also external modules for sh, Java and even PHP. Maybe also others, I don't know all.
MySQL currently. But one of the important reasons for my choosing Drupal was due to the available pgSQL support, and the fact that all queries were supposedly ANSI SQL compliant. So if this is about whether to stop pgSQL support, please don't!
I would also like to see a poll on which version of MySQL people use and which versions they want to be able to use. In addition, what about MySQL Cluster or other MySQL offerings?
While it certainly is useful to know who's running what, it may be good to know why and, for me, to ask a similar but different question, "Should we continue to improve support for Postgresql, if it has features and characteristics unavailable in MySQL?"
However, practically, I understand it is more efficient to specialize.
It's a nice idea to ask what database people would like to use. I currently do all projects I can on PostgreSQL, but I had to use MySQL for Drupal because I got too many error messages from additional modules and because of not enough time to figure out all the errors...
So I had to vote for MySQL above, but I'd gladly use PostgreSQL if possible. Maybe I should give it another try with the next big update...
Good idea. This goes for PHP too. My host upgrades to the latest and greatest of everything, but some folks like to stick with the older stuff becasue they know it works. What versions need to the supported?
XAMPP is great, even for small public (non-test) sites. I REALLY would like to see more support for this plaform in the Drupal docs. XAMPP makes the installation SO much easier!!!
Good for testing, but not for production sites. Unless you tweak the code and make it more secure as they suggest in the documentation.
-- Webmaster Resources for Business Websites
I would much prefer to use Postgres. It's all around a better system; but my web host doesn't offer it, and Drupal's much better tested with MySQL, so I'll stick with that.
I would prefer to use PostgreSQL, but use MySQL because not all contributed modules support Postgres. My impression is that Drupal core is also primarily written/tested for MySQL.
I twould be nice to have proper PostgreSQL support in other modules, and properly supported in the main build. I think it is better supported in 4.7 though.
At last, after nearly 5 years of drupal.org, drupal.org has the poll activated. Hooray for that!
/me longs for the drop.org days :-)
remark regarding content of poll: i dont think it is very usefull.
Next up:
Where do you host?
What webserver do you run?
I drupal installed in a subdirectory?
What theme do you use?
What browser do you use for accessing your drupal site?
None of the questions give real answers, all of the answers will lead to new questions... which wont real answers.
I do think we need an opt-in call home for collecting data like this.
I've never used postgress and have no idea how popular it is. I think this poll is interesting and relevant to the Drupal community.
The other polls you listed are redundant or just dumb, and I don't think we'll see them here. :)
While postgress doesn't appear to be commonly used (at this point in the survey), Drupal's DB abstraction effort is a good thing and broadens the audience.
However, I'm not that familiar with its effectiveness. If it is a well implemented abstraction, it would be nice to see some new DBs added to the list of those supported. Maybe there's an interesting idea for a poll. I suppose Oracle and MSSQL might be candidates. Then again, we'll probably have to wait until a drupal dev has a personal need for such support.
One inconvenience in using Drupal is the "sequences" table. It's there only because other database (version?) doesn't support "Auto Increment" in primary keys. And it causes quite a bit of trouble when I move data from one db to another (I'm sharing multiple sites in one db).
I suppose if Drupal can mainly support one type of database (since majority are using mysql 4.x), but also support other database with some add-on modules, then it would make the development effort easier.
I'm not saying Drupal shouldn't support other database (I think it should function without error with most db). I think it may be better to focus and optimized more on the mainstream database.
i think its important for drupal to continue and improve its support for postgres. the cache problem is one i hope is fixed in 4.7, as its a great feature that i haven't been able to use yet.
having support for more than one database has too many advantages to mention here, but i think all users benefit in at least some small way from the run on effects.
This is someone who is curious about how many site visitors are using what. As long as there is a maintainer, there will be a schema for PostGRE. If the person using MS SQL supplies a schema for inclusion, then that would be included.
Currently Drupal does not work properly with Postrges, so anyone that wants to use postgres on a serious site will at some stage be forced to change.
Please don't use FUD language like this. Either back it up with real bug-issues or present patches. Just saying " it does not work" does no good. It will turn away people looking for postgreSQL supported CMses and it makes Drupal look bad.
Cacheing doesn't quite work on PostgreSQL yet, also it needs patching to use a socket with postgres. I do have a live site working with a PostgreSQL database and a few patches. It works quite well though.
For the cache problems, there's a proposed patch for current cvs at http://drupal.org/node/10407#comment-53271
This bug is very old (pre-4.6 I think) and I hope it will be fixed for 4.7
I don't think it will be fixed in 4.6 because the changes to db_query() are quite intrusive (unless there's an other patch proposed)
The sockets issue - iirc the problem is with the $db_url syntax, there was an issue filled but no real resolution was proposed...
If you have patches against drupal please submit an issue on drupal.org, this could help making drupal better.
The mysql support is of course better - "they" have much more people working on drupal and making patches ;)
Books, the Cache, and even permissions are broken for me. I've asked for help, presented fixes, and been ignored.
I'm afraid the challenge "make your own" does not work for me. I'm not a PHP developer and have no intention of learning, I want to be a drupal user though. If the pre-reqs included being forced to learn to become a PHP dev, you'd discover Drupal being a lot less successful.
This is the last mysql vs. postgresql comment I leave here and only as a warning. The next one will be deleted. If there is a need, accounts will be blocked.
--
Read my developer blog on Drupal4hu.
Improved support in Drupal for PostgreSQL would be nice. That is assuming that the current support is not that good. I have never used Drupal with PostgreSQL so I don't know.
MySQL is generally the de facto choice for people using Drupal on the web because web hosts do not generally offer PostgreSQL. However people using Drupal on the intranet might want to use it with PostgreSQL instead of MySQL.
I've thought for awhile now that a more robust DB abstraction layer would help some of the issues I'm reading here. I've talked a little bit about this before, but it's always been met with: "Why would we need something like that? MySQL works fine." It would be really nice if all you had to do to switch to a new database was re-write an abstract data class that has a well-defined interface. I am aware that drupal has a light-weight DB Abstraction layer right now, but I'm talking about something more robust - something that would take all the SQL code out of drupal and move it into one module. I've come to believe this is a good move, based on the sheer amount of MySQL specific code in the drupal codebase. Something like this would allow drupal to run in instances where a database wasn't even available (file-based drupal). However, based on some previous conversations, I imagine if something like this were ever implemented it would have to live in a different branch, because I doubt the majority of the drupal community would see this as a "good" thing.
ADOdb is used for a number of other open source projects because
- there are lots of people using ADOdb
- they started making it OO
- It has a schema build facility so that your database load can be database independent.
If you use ADOdb then you are one step closer to plugging in an open source CRM module, XRMS, and the open source accounting/ERP product webERP.
I've done database abstraction on several other projects in several other languages and I find that making an object to access the database through seems to be the most flexible/maintainable way to accomplish a total abstraction of the database. This would work like a charm for the drupal core, but could create problems for some of the add-on modules that extend the data model to get their work done. There are ways to get around this, like providing some basic lower-level SQL abstraction as part of your DB abstraction (e.g. create_table). Additionaly, this would make some of the add-on modules work cross-database with almost no work, once converted. Worst case scenario, the module can subclass the DB Abstraction class, adding it's own methods and properties and making that version the globally available one. These objects could be standardized through naming conventions so it would be easy to import the proper file for the proper DB subsystem. Of course, the other suggestions of sticking to lowest common denominator standard SQL in the modules distributed with the core would help the situation as well.
This may sound a little extreme - and it may be - but the whole point is to get the SQL out of the code. I find that my biggest beef with most PHP applications is the intermixed SQL code. At the very least, moving all SQL code into a PHP module that is called via functions rather than inline can provide a good start.
This is all quite "off the top of my head", but now that I'm thinking about it, I may begin trying to convert the core again to see how things go - if anyone thinks this work would be of any merit please let me know.
real db abstraction is a beautiful idea. but it's also a lot of work. it would be a major operation to convert drupal to true db abstraction (where there would be virtually no SQL outside of the abstraction API and all data would be accessed through an OO interface). it would require re-writing everything that accesses the DB.
before we start talking about DB abstraction, i think there are some questions that should be answered. why would we want such a layer? of course, compatibility with XXXDB is cool in theory, and it would please the marketing department (if we had one), but what is the current breakdown of mysql to postgress right now? what is the likelyhood that folks spending $500 million for Oracle are going to be choosing a $0 CRM solution? how many databases are out there that are even worth supporting?
the major benefit of db abstraction would be that it would force module developers to be truly compatible with all DBs drupal supported. as it is now, plenty of modules are "mysql only" or "not tested with postgress". abstraction would eliminate all that.
afaik, database.inc is very flexible. it could be used to create support for oracle, sqlite or whatever. i believe core is currently restricted to code that uses database.inc properly (no mysql specific stuff, table {renaming_syntax} etc... and module developers who know what they are doing can pretty easily write compatible modules by simply not depending on db-specific features.
in my head, the cost/benefit definitely doesn't make much of a case for writing a new abstraction layer.
i think efforts would be better spent cleaning up modules that don't adhere to abstraction rules and maybe even writing some new drivers for new DBs.
I have customers who have Oracle because Oracle was "the choice" when they built their first database.
Some have Oracle because they purchased an application and the application sales person said they had to have Oracle. If you are stuck with a closed source produce then you cannot change the code to use another database.
Supporting two brands of database is painful when you have just one database expert in your company. Converting from Oracle to MySQL is not an option when you have many databases built into many applications and all the applications have to run every day.
It would be interesting to know how extensible our current approach to db abstraction (write ANSI SQL) works with other databases. If this works, you should be able to create a database.oracle.inc and be happy.
I tried to use PEAR:DB on one project because one of the customer's IT staff wanted to use PEAR. PEAR had several DB modules and none of them let us write logical SQL that is database independent. Can PEAR:DB
- create dates in the correct format for each database?
- create schema in the correct format for each database?
- handle the limit clause for every database including those that do not have limit?
ADOdb seems to be leading the competitors in many compatibility areas without moving far away from straight SQL. You can write your SQL for your database then make minimal changes to make it database independent.
PEAR:DB did not have an equivalent when I tried PEAR:DB. How do you handle each case in PEAR:DB?
It is not difficult to create a schema for other databases. The big problem is that the SQL commands in the code do not follow the SQL standards in many cases (probably because it had been done for mysql) and this breaks the possibility of using it with other databases.
Drupal 4.6.3 is difficult to use with postgresql in production (too many errors) but the last CVS version looks very good, at least drupal core (many modules are still done only with mysql sql syntax). The core comes now with forum, polls, books, blogs, etc included, very good. I cannot wait for 4.7.0
I know many people that do not use drupal because they have to use MySQL. It is about time (specially when you use a DB abstraction like pear) that people start writing standard SQL, then it would be very easy for the users to choose the database they want to use.
It is difficult to start using mysql (and in many cases, 99%, you don't) when you are use to a robust, stable, fast,acid database like PostgreSQL, that scale so good in very busy sites.
Almost all errors with postgresql in 4.6.3 are because the code uses mysql sql syntax many times. Try to do this, activate 'strict mode' in mysql 5 and you would probably get many of the errors postgresql gets.
From "What's New in MySQL 5.0"
"Strict Mode and Standard Error Handling: MySQL 5.0 added a strict mode where by it follows standard SQL in a number of ways in which it did not previously."
As I said: Tha cvs version of drupal has fixed all the problems I found in core due to mysql sql syntax. Many modules have still problems. (core to me is what I get when I download the drupal tar.gz file without installing extra modules)
As many people use MySQL and not PostGRE, perhaps you could add some hints/pages in the handbook on how to avoid MySQL specific syntax in contributed modules. This would help many people who do not know the difference now.
Don't specify length of numeric types (use integer, rather than integer(11)
Make sure that statements using IF use boolean values, not integer values. Consider using a boolean type rather than an integer type for table columns meant to store boolean flags.
When doing a value comparison against an integer value, do not put quotes around the value (that forces it to be a string).
Use strict mode for testing in MySQL 5.
When passing text values to SQL commands, make sure they are in single quotes, not double quotes.
Make sure that when you have integer field in DB, you do not attempt to insert '' for it. One of the most common PostgreSQL errors is "invalid input syntax for integer", and it almost always means that a module has attempted to insert zero-length string as an integer value.
I don't know much about MySQL, but if the strict mode in MySQL 5 works as I think it does, using it should really fix most compatibility errors like this. Every developer should always use it.
We do not use REPLACE in core. database.mysql uses that (unnecessary) but that's mysql specific anyways. The integer(11) to integer is on its way, I am not sure whether we changed pver already but discussed it for sure.
IF, on the other hand is simply implemented in postgresql as a user defined function. Recently you do not even need pl/pgsql (or whatever) just plain SQL.
'%d' was cleaned out a few days ago.
--
Read my developer blog on Drupal4hu.
I use PostgreSQL, and have since 4.5
As other posters have said, some non-core modules don't have PostgreSQL support. In some cases all you need to do is translate the create table structures (not too difficult if you know PostgreSQL) and you're done. In other cases it is a little more difficult.
I have simply stuck to using those features that are supported under PostgreSQL, since I have 5 years experience developing PostgreSQL apps (in house for my organisation) and I have never used MySQL for any large projects.
Having a poll in the news feed, being aggregated by a news reader which doesn't have a feature to ignore updated stories (google reader), is unfortunately very annoying. Everytime the feed is read, the new numbers on the poll indicate new content. I'm seeing this story about every third story in my feed reader.
I use the PHP mysql extension and will switch to mysqi as soon as the Drupal 4.7.0 upgrade is out of the way. I will use MySQL 5 with mysqli. How will Drupal handle mysql/myslqi?
We hope that it will handle it just fine. :)
I recommend that you get the release candidate once it becomes available and run some tests.
-- Drupal services My Drupal services
I have written and someone else did also an SQLite layer -- not hard at all. SQLite locks DB on writing, and this causes performance problems. Also 2.8 has some severe bugs. 3.x is much better but that's natively supported in PHP 5.1 only which is not even out yet.
Ah and someone would need to maintain that...
--
Read my developer blog on Drupal4hu.
Are you sure this site is Drupal? Is this pre-4.4, or heavily customized?
You have all these s=zzzzzzzzz in links.
You also have hxxp://de.castlecops.com/forum/newreply.php?s=72b56c6e321235ffb8a735446f9013f0&&do=newreply&noquote=1&t=122
And
hxxp://de.castlecops.com/forum/register.php
What is going on?
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
I currently run MySQL, although I would much prefer to run PostgreSQL.
I've had too many problems with the instability of MySQL when running under significant load to trust it very far. MySQL is the only daemon for which I've ever had to write a watchdog cron job (apart from a dodgy terminal server authentication daemon back in the day).
When I first installed a test drupal (about a month ago) I used postgres as it was claimed that it was supported.
However, I encountered many errors and bugs in the code - then when I looked through the sql file to set up all the tables I noticed that half of it was mysql code and wouldn't work anyway.
Thus my "production" (still testing) is using mysql. :-(
Having said that - I would *much* prefer to use oracle since our company database is oracle and using that would mean less dbs to support, easier backup, etc. Most of the data I want to display via drupal will be coming from oracle.
I've ran drupal 4.4 with mysql for more than 1 year. Now I moved to drupal 4.6 with postgreSql.
Drupal, including non-core modules, supports mysql perfectly. When I tried postgresql, I met many problems and had to find pathes or done my own. I think it's a important reason for some people using mysql that they can avoid these troubles.
:)
I am considering Drupal but since my experience with MSSQL goes back to its inception and the 40+ projects running on that server are already using MSSQL I am still wary of installing and supporting mySQL as well.
As for the politics concerning my vs ms sql I sum it up like this:
Before stored procedure support there was no way I was going to use mySQL. Who the heck wants to write dynamic sql in a hostile environment like the web? Seemed to me the only people using mySQL then was open source zealots and/or DBA hobbiest.
Now that mySQL supports stored procedures (with typed params I suppose/hope) it is at least on the table as a consideration. Now I only need a reason. Cost isn't an issue since I already own MSSQL and even if I didn't MSDE can handle a pretty good load of hundreds of simultanous users and is free as well.
So at this time the only reason for me to use mySQL is so I don't have to mod all this great free software thats available.
Its the same kind of virtous circle that benefited Microsoft, why use a different OS when there is so much software for Windows.
If MSSQL was supported I would have already installed Drupal.
Of all the software MS ever wrote MSSQL is the best of it.
This thread is almost a year old.
This is Open Source software. There was once a maintainer for a MS SQL schema. Should you choose to contribute one it will be accepted. It merely needs a contributor and maintainer as does anything else in Drupal core.
Hello Lonecrow,
I have used MySQL, MSSQL, and other databases for projects from quick experiments (a few minutes) up to large scale projects for big companies. Oracle is the most difficult to use and MySQL the easiest. I can also use MySQL easily on every useful server operating system out there. For that reason I use MySQL even when creating a demonstration database for a system that will be implemented in MSSQL. That MySQL ease of installation and use is one reason why so many projects start with MySQL and never change to anything else.
I have used ASP as well as PHP and performed conversions between the two. Converting from MSSQL to MySQL is so easy that it is the easiest part of an ASP to PHP conversion, far easier than an Oracle to MySQL or Oracle to MSSQL conversion.
If you really want database independence then convert all your SQL to one of the SQL standards. MySQL supports SQL 92 and PostgreSQL supports SQL 99. PostgreSQL is harder to install on Windows and MySQL release 5 gives you most of the features of PostgreSQL, which is another reason to stick with MySQL.
Of all the software MS ever wrote, NT is the best. I know from experience of installing thousands of systems. MSSQL is a very good upgrade to the Sybase that MS purchased as the base for MSSQL but it is very hard to find someone that knows how to tune MSSQL or to diagnose problems with MSSQL.
When there is a conflict between two applications accessing tables in a shared database, the quickest solution is often to invest a couple of hours running up a Windows or Linux machine, Apache, PHP, PHPMyAdmin, and MySQL, transfer some of the tables to MySQL then run one of the applications on the MySQL machine.
Overall MySQL provides a simple database solution that works equally well in an MS environment or one of the alternative environments. You can interconnect environments with ODBC. If you are considering any change away from Microsoft software then MSSQL to MySQL is the easiest followed by ASP to PHP, then IIS to Apache and both can be performed without changing your operating system.
One question. I have used stored procedures in Oracle to make up for shortfalls in Oracle. When do you use stored procedures in MSSQL?
mysql is now my choice
mysql is now my choice, after long time trying to make stuff functional in postgresql, the interest for postgresql is just to small, especially if you want to use addiotional modules :(
pgsql works mostly dandy
If one takes a bit of time to do the research, postgres works quite well. I have contributed some tidbits to drupal, and maybe one day they will be included, like:
* http://drupal.org/node/12071
* http://drupal.org/node/21220
* http://drupal.org/node/22537
* http://drupal.org/node/36481
If one wants, he can do. To paraphrase Kennedy, don't ask what Drupal can do for you, but what you can do for Drupal. ;)
Postgres 8.1.0 works quite well with Drupal, I might add. I did already test it and it runs on my site.
Pgsql has massive breakage
Currently broken (as of 4.6) in Postgres:
Currently buggy, but apparently functional:
I have a site running under Postgres... but it took massive amounts of effort to get running and continues to be high maintenance every time I upgrade something. If you run Postgres and use external modules, or heavily stress your site, expect things to break. Don't try it if you don't have fairly good PHP and SQL skills so you can debug.
Hard but not Impossible: Community is Key to PostgreSQL Success
I run two mysql based drupal instances (one is civicspace distro), and one PostgreSQL. PostgreSQL being a prefered standard at my workplace.
The difference in the amount of time needed to successfully keep up to date with psql vs. mysql is significant. The upgrade of my PostgreSQL site to 4.5x took upwards of 30 hours, including several posts to module maintainers etc. Drupal MySQL upgrades often happen in terms of minutes. (Note: I am not a developer, nor a person with more than SysAdmin level database knowledge). I was unable to upgrade to 4.6x, so my site remains out of date.
I have been unable to resolve slow site response issues in a backport of the node_privacy_byrole module, which I find essential to running an workplace internet/intranet combined functionality site.
In the past I had worked with Adrian the former psql maintainer, who was quite helpful in resolving issues. But primarily the problem seemed to be a combination of the following:
Its difficult to stay active enough in the community to resolve these things. I find myself, even now, coming back to drupal.org considering whether to attempt an upgrade to 4.6.x again, wait for 4.7.x, or ask about the difficulty in switching from PostgreSQL to MySQL for that site. Which makes this poll and thread extremely timely.
I do think that a sign of Drupal's maturity would be to support multiple databases with equal proficiency. That requires, developer education, user participation, and an aggregated postgreSQL knowledge resource.
The only such central place for PostgreSQL stuff I have known about is:
PostgreSQL specific guidelines
Perhaps what Drupal needs most to improve Postgres support is to use its own collaboration engine to unify the postgres community. For me it is impossible to keep up with the amount of information on this site. I need a starting place.
The most positive thing that drupal postgres has going for it, is the fact that I have found many Postgres users to be SQL experts, offering sound advice and patches. The stuff is there to both educate module developers and support users.
Thanks to all who have worked so hard over the years inspite of the complaints.
Support Queues for databases
What we should have akin to some other support ticketing applications is some more projects for database specific problems.
Like postgres, but I'm sure a few problems have also driven MySQL folks nuts.
If there was such a project for the Drupal core (the postgres problems for contributions get discussed in contributions), I'd most certainly participate.
I don't understand what you want to say
Could you elaborate/rephrase?
Spam prevention
I have made Jeremy's module from kernel trap run here. I know I should mail him the patches so his stuff works with Postgres as well.
that doesn't make sense to me
With all due respect, why would you want to use PostgreSQL when MYsql is easier???
"if one takes a bit of time to do the research, postgres works quite well"
Why should we? Just because you like postgresSQL? Getting a site up and running and installing modules sometimes can take there toll and of course time. We don't have the time to do "a little research". You’re going to need a better reason to sell me on the idea.
easier?
Hello
I would like to know why MySQL is easier than PostgreSQL. Easy to administrate, install, upgrade, maintain?
History
PostgreSQL used to be better for SQL nuts because PostgreSQL supported SQL99 and MySQL had only SQL92.
MySQL was easier for PHP Web sites because:
* MySQL had autoincrement
* MySQL had choice of table types for better read performance.
* MySQL had PHPMyAdmin
Today MySQL 5 has about the same SQL as PostgreSQL. There is a PostgreSQL version of PHPMyAdmin. ADOdb lets you mix both databases in the one site and have your SQL automatically converted between the two.
If you want to write stored procedures then MySQL 5 lets you write stored procedures in SQL. I do not know if PostgreSQL has that or if you are still stuck with Perl.
Back when 95% of Web development was on Windows or NT based workstations, MySQL installed easily on both but PostgreSQL required Cygwin. For many years Cygwin was a real pig to install and use. Now that Linux has grown up to equal NT, Microsoft has downgraded NT to Windows, PostgreSQL has built an easier install system, and people are running twelve different operating systems under VM, You can have every table in a different database under different database software and build a system that spends 98.98 percent of the CPU time virtualising without actually retrieving data.
Me? I will stick with MySQL because I can use fast MyIsam tables for things that are mostly read and InnoDB tables when I need transactions.
I do enjoy replacing Oracle with PostgreSQL or MySQL. It is almost as much fun as replacing ASP with PHP.
petermoulding.com/web_architect
If you want to write stored
Well, let's see... There's of course SQL and C... and PL/pgSQL, PL/Tcl, PL/Perl, PL/Python in the standard PostgreSQL distribution. There are also external modules for sh, Java and even PHP. Maybe also others, I don't know all.
--
Polska strona o Drupalu: http://drupal.cvbge.org
when it comes to Drupal
you said it!
MySQL currently. But one of
MySQL currently. But one of the important reasons for my choosing Drupal was due to the available pgSQL support, and the fact that all queries were supposedly ANSI SQL compliant. So if this is about whether to stop pgSQL support, please don't!
:)
Thanks.
MSSQL
MSSQL
are you sure?
you are a member for 6 weeks, the mssql code has been unmaintained for 6 month or so and still you use it?
it can be true, just checking...
--
groets
bertb
No MSSQL know use its a Feature
Sorry, hope is come soon. ;)
Only does the file "database.mssql.inc" have to be adapted?
Then Let's go!
gruß DOCI
distinctions
I would also like to see a poll on which version of MySQL people use and which versions they want to be able to use. In addition, what about MySQL Cluster or other MySQL offerings?
While it certainly is useful to know who's running what, it may be good to know why and, for me, to ask a similar but different question, "Should we continue to improve support for Postgresql, if it has features and characteristics unavailable in MySQL?"
However, practically, I understand it is more efficient to specialize.
nice idea
It's a nice idea to ask what database people would like to use. I currently do all projects I can on PostgreSQL, but I had to use MySQL for Drupal because I got too many error messages from additional modules and because of not enough time to figure out all the errors...
So I had to vote for MySQL above, but I'd gladly use PostgreSQL if possible. Maybe I should give it another try with the next big update...
Good idea. This goes for PHP
Good idea. This goes for PHP too. My host upgrades to the latest and greatest of everything, but some folks like to stick with the older stuff becasue they know it works. What versions need to the supported?
Advanced Web Design
XAMPP All the WAY!!!
XAMPP is great, even for small public (non-test) sites. I REALLY would like to see more support for this plaform in the Drupal docs. XAMPP makes the installation SO much easier!!!
XAMPP
The installation procedure is the same for XAMPP as for any other host, it worked for me great. What do you mean more support?
I use XAMPP As Well
Maybe we could talk to the XAMPP folks and get Drupal into XAMPP by default. It would give people a great taste of what they can do with a LAMP stack.
--
Mike H.
http://www.amountaintop.com
Good for testing, but not
Good for testing, but not for production sites. Unless you tweak the code and make it more secure as they suggest in the documentation.
--
Webmaster Resources for Business Websites
I use MySQL, but...
I would much prefer to use Postgres. It's all around a better system; but my web host doesn't offer it, and Drupal's much better tested with MySQL, so I'll stick with that.
Would prefer PostgreSQL, but asking for problems?
I would prefer to use PostgreSQL, but use MySQL because not all contributed modules support Postgres. My impression is that Drupal core is also primarily written/tested for MySQL.
Going PostgreSQL
I twould be nice to have proper PostgreSQL support in other modules, and properly supported in the main build. I think it is better supported in 4.7 though.
[strike]eating own dogfood[/strike]drinking own champapgne
At last, after nearly 5 years of drupal.org, drupal.org has the poll activated. Hooray for that!
/me longs for the drop.org days :-)
remark regarding content of poll: i dont think it is very usefull.
Next up:
Where do you host?
What webserver do you run?
I drupal installed in a subdirectory?
What theme do you use?
What browser do you use for accessing your drupal site?
None of the questions give real answers, all of the answers will lead to new questions... which wont real answers.
I do think we need an opt-in call home for collecting data like this.
--
groets
bertb
Actually, there were some
Actually, there were some old polls in the database that I unpublished. Don't know if they were imported from drop.org.
i think it's a good poll
I've never used postgress and have no idea how popular it is. I think this poll is interesting and relevant to the Drupal community.
The other polls you listed are redundant or just dumb, and I don't think we'll see them here. :)
While postgress doesn't appear to be commonly used (at this point in the survey), Drupal's DB abstraction effort is a good thing and broadens the audience.
However, I'm not that familiar with its effectiveness. If it is a well implemented abstraction, it would be nice to see some new DBs added to the list of those supported. Maybe there's an interesting idea for a poll. I suppose Oracle and MSSQL might be candidates. Then again, we'll probably have to wait until a drupal dev has a personal need for such support.
--
Living in fear of patch hell?
Want a stable development environment?
Support Dev Releases: http://drupal.org/node/30903
Support Code cleanup too: http://drupal.org/node/28540
MySQL and Oracle
I use MySQL as the main DB for Drupal, but I have some blocks/node that display information from our (my company) main DB, which is Oracle.
It was pretty tough to set it up, but it works fine.
New version of MySql and Auto Increment
I am using MySql 4.x only.
One inconvenience in using Drupal is the "sequences" table. It's there only because other database (version?) doesn't support "Auto Increment" in primary keys. And it causes quite a bit of trouble when I move data from one db to another (I'm sharing multiple sites in one db).
I suppose if Drupal can mainly support one type of database (since majority are using mysql 4.x), but also support other database with some add-on modules, then it would make the development effort easier.
I'm not saying Drupal shouldn't support other database (I think it should function without error with most db). I think it may be better to focus and optimized more on the mainstream database.
two as a minimum
i think its important for drupal to continue and improve its support for postgres. the cache problem is one i hope is fixed in 4.7, as its a great feature that i haven't been able to use yet.
having support for more than one database has too many advantages to mention here, but i think all users benefit in at least some small way from the run on effects.
MySQL only
MySQL only
See ya, Darken
This hurts drupal
Don't use this vote to justify not working on postgres.
Currently Drupal does not work properly with Postrges, so anyone that wants to use postgres on a serious site will at some stage be forced to change.
So then we have a vote to see what people are using, and from there we say - "look there is no-one using postgres, we don't need to support it"
what?
This is someone who is curious about how many site visitors are using what. As long as there is a maintainer, there will be a schema for PostGRE. If the person using MS SQL supplies a schema for inclusion, then that would be included.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
This poll was actually set
This poll was actually set up by our Postgres maintainer.
--
Drupal services
My Drupal services
bugs with patches?
Please don't use FUD language like this. Either back it up with real bug-issues or present patches. Just saying " it does not work" does no good. It will turn away people looking for postgreSQL supported CMses and it makes Drupal look bad.
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
ex: caching
Cacheing doesn't quite work on PostgreSQL yet, also it needs patching to use a socket with postgres. I do have a live site working with a PostgreSQL database and a few patches. It works quite well though.
Hello. For the cache
Hello.
For the cache problems, there's a proposed patch for current cvs at http://drupal.org/node/10407#comment-53271
This bug is very old (pre-4.6 I think) and I hope it will be fixed for 4.7
I don't think it will be fixed in 4.6 because the changes to db_query() are quite intrusive (unless there's an other patch proposed)
The sockets issue - iirc the problem is with the $db_url syntax, there was an issue filled but no real resolution was proposed...
If you have patches against drupal please submit an issue on drupal.org, this could help making drupal better.
The mysql support is of course better - "they" have much more people working on drupal and making patches ;)
It's not FUD
Books, the Cache, and even permissions are broken for me. I've asked for help, presented fixes, and been ignored.
I'm afraid the challenge "make your own" does not work for me. I'm not a PHP developer and have no intention of learning, I want to be a drupal user though. If the pre-reqs included being forced to learn to become a PHP dev, you'd discover Drupal being a lot less successful.
Currently Drupal does not
Currently Drupal does not work properly with Postrges, so anyone that wants to use postgres on a serious site will at some stage be forced to change.
It is difficult to believe or I can not understand how MySQL can be used in a serious, large, busy site. And this is not a FUD.
Warning
This is the last mysql vs. postgresql comment I leave here and only as a warning. The next one will be deleted. If there is a need, accounts will be blocked.
--
Read my developer blog on Drupal4hu.
You mean ....
You mean like Slashdot or Yahoo Finance?
These are serious, large and busy sites that are using MySQL.
You decide what is FUD.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
Postgresql does work with Drupal
I am running production Drupal on Postgresql. Core Drupal works very well- for my purposes it is great.
I know there are some modules which have problems with Drupal but why not submit a bug/fix?
BTW, I submitted a fix for gsitemap on Postgresql a couple of weeks ago.
If Drupal did not work on Postgresql, I would not be using Drupal.
Improved support for PostgreSQL would be nice
Improved support in Drupal for PostgreSQL would be nice. That is assuming that the current support is not that good. I have never used Drupal with PostgreSQL so I don't know.
MySQL is generally the de facto choice for people using Drupal on the web because web hosts do not generally offer PostgreSQL. However people using Drupal on the intranet might want to use it with PostgreSQL instead of MySQL.
My Drupal-powered Blog: ThoughtfulChaos - Varun's Blog
DB Abstraction
I've thought for awhile now that a more robust DB abstraction layer would help some of the issues I'm reading here. I've talked a little bit about this before, but it's always been met with: "Why would we need something like that? MySQL works fine." It would be really nice if all you had to do to switch to a new database was re-write an abstract data class that has a well-defined interface. I am aware that drupal has a light-weight DB Abstraction layer right now, but I'm talking about something more robust - something that would take all the SQL code out of drupal and move it into one module. I've come to believe this is a good move, based on the sheer amount of MySQL specific code in the drupal codebase. Something like this would allow drupal to run in instances where a database wasn't even available (file-based drupal). However, based on some previous conversations, I imagine if something like this were ever implemented it would have to live in a different branch, because I doubt the majority of the drupal community would see this as a "good" thing.
!>-artlogic-<!
I am intersted in having a
I am intersted in having a more flexible db abstraction layer. Do you have any particular recommendations?
--
Drupal services
My Drupal services
ADOdb
ADOdb is used for a number of other open source projects because
- there are lots of people using ADOdb
- they started making it OO
- It has a schema build facility so that your database load can be database independent.
If you use ADOdb then you are one step closer to plugging in an open source CRM module, XRMS, and the open source accounting/ERP product webERP.
petermoulding.com/web_architect
I've done database
I've done database abstraction on several other projects in several other languages and I find that making an object to access the database through seems to be the most flexible/maintainable way to accomplish a total abstraction of the database. This would work like a charm for the drupal core, but could create problems for some of the add-on modules that extend the data model to get their work done. There are ways to get around this, like providing some basic lower-level SQL abstraction as part of your DB abstraction (e.g. create_table). Additionaly, this would make some of the add-on modules work cross-database with almost no work, once converted. Worst case scenario, the module can subclass the DB Abstraction class, adding it's own methods and properties and making that version the globally available one. These objects could be standardized through naming conventions so it would be easy to import the proper file for the proper DB subsystem. Of course, the other suggestions of sticking to lowest common denominator standard SQL in the modules distributed with the core would help the situation as well.
This may sound a little extreme - and it may be - but the whole point is to get the SQL out of the code. I find that my biggest beef with most PHP applications is the intermixed SQL code. At the very least, moving all SQL code into a PHP module that is called via functions rather than inline can provide a good start.
This is all quite "off the top of my head", but now that I'm thinking about it, I may begin trying to convert the core again to see how things go - if anyone thinks this work would be of any merit please let me know.
!>-artlogic-<!
practicality
real db abstraction is a beautiful idea. but it's also a lot of work. it would be a major operation to convert drupal to true db abstraction (where there would be virtually no SQL outside of the abstraction API and all data would be accessed through an OO interface). it would require re-writing everything that accesses the DB.
before we start talking about DB abstraction, i think there are some questions that should be answered. why would we want such a layer? of course, compatibility with XXXDB is cool in theory, and it would please the marketing department (if we had one), but what is the current breakdown of mysql to postgress right now? what is the likelyhood that folks spending $500 million for Oracle are going to be choosing a $0 CRM solution? how many databases are out there that are even worth supporting?
the major benefit of db abstraction would be that it would force module developers to be truly compatible with all DBs drupal supported. as it is now, plenty of modules are "mysql only" or "not tested with postgress". abstraction would eliminate all that.
afaik, database.inc is very flexible. it could be used to create support for oracle, sqlite or whatever. i believe core is currently restricted to code that uses database.inc properly (no mysql specific stuff, table {renaming_syntax} etc... and module developers who know what they are doing can pretty easily write compatible modules by simply not depending on db-specific features.
in my head, the cost/benefit definitely doesn't make much of a case for writing a new abstraction layer.
i think efforts would be better spent cleaning up modules that don't adhere to abstraction rules and maybe even writing some new drivers for new DBs.
--
Living in fear of patch hell?
Want a stable development environment?
Support Dev Releases: http://drupal.org/node/30903
Support Code cleanup too: http://drupal.org/node/28540
Oracle
I have customers who have Oracle because Oracle was "the choice" when they built their first database.
Some have Oracle because they purchased an application and the application sales person said they had to have Oracle. If you are stuck with a closed source produce then you cannot change the code to use another database.
Supporting two brands of database is painful when you have just one database expert in your company. Converting from Oracle to MySQL is not an option when you have many databases built into many applications and all the applications have to run every day.
petermoulding.com/web_architect
It would be interesting to
It would be interesting to know how extensible our current approach to db abstraction (write ANSI SQL) works with other databases. If this works, you should be able to create a database.oracle.inc and be happy.
This is unlikely to happen from anybody who does not use oracle, though.
--
Drupal services
My Drupal services
PEAR::DB
I use the PEAR::DB module in other projects. It is robust, well-tested and definately worth looking into.
PEAR::DB supports PHP4, PHP5, transactions, and loads of database drivers: fbsql, ibase, informix, msql, mssql, mysql, mysqli, oci8, odbc, pgsql, sqlite and sybase.
http://pear.php.net/package/DB
Does PEAR:DB translate SQL?
I tried to use PEAR:DB on one project because one of the customer's IT staff wanted to use PEAR. PEAR had several DB modules and none of them let us write logical SQL that is database independent. Can PEAR:DB
- create dates in the correct format for each database?
- create schema in the correct format for each database?
- handle the limit clause for every database including those that do not have limit?
ADOdb seems to be leading the competitors in many compatibility areas without moving far away from straight SQL. You can write your SQL for your database then make minimal changes to make it database independent.
PEAR:DB did not have an equivalent when I tried PEAR:DB. How do you handle each case in PEAR:DB?
petermoulding.com/web_architect
More standard SQL support, please
It is not difficult to create a schema for other databases. The big problem is that the SQL commands in the code do not follow the SQL standards in many cases (probably because it had been done for mysql) and this breaks the possibility of using it with other databases.
Drupal 4.6.3 is difficult to use with postgresql in production (too many errors) but the last CVS version looks very good, at least drupal core (many modules are still done only with mysql sql syntax). The core comes now with forum, polls, books, blogs, etc included, very good. I cannot wait for 4.7.0
I know many people that do not use drupal because they have to use MySQL. It is about time (specially when you use a DB abstraction like pear) that people start writing standard SQL, then it would be very easy for the users to choose the database they want to use.
It is difficult to start using mysql (and in many cases, 99%, you don't) when you are use to a robust, stable, fast,acid database like PostgreSQL, that scale so good in very busy sites.
It would help if you could
It would help if you could pinpoint the places in core (!) where we don't use ANSI SQL.
--
Drupal services
My Drupal services
Almost all errors with postgresql in 4.6.3
Almost all errors with postgresql in 4.6.3 are because the code uses mysql sql syntax many times. Try to do this, activate 'strict mode' in mysql 5 and you would probably get many of the errors postgresql gets.
From "What's New in MySQL 5.0"
"Strict Mode and Standard Error Handling: MySQL 5.0 added a strict mode where by it follows standard SQL in a number of ways in which it did not previously."
As I said: Tha cvs version of drupal has fixed all the problems I found in core due to mysql sql syntax. Many modules have still problems. (core to me is what I get when I download the drupal tar.gz file without installing extra modules)
As many people use MySQL and
As many people use MySQL and not PostGRE, perhaps you could add some hints/pages in the handbook on how to avoid MySQL specific syntax in contributed modules. This would help many people who do not know the difference now.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
MySQLisms
I'll start with a few:
Don't use REPLACE INTO.
Don't specify length of numeric types (use integer, rather than integer(11)
Make sure that statements using IF use boolean values, not integer values. Consider using a boolean type rather than an integer type for table columns meant to store boolean flags.
When doing a value comparison against an integer value, do not put quotes around the value (that forces it to be a string).
Use strict mode for testing in MySQL 5.
When passing text values to SQL commands, make sure they are in single quotes, not double quotes.
Some more
Make sure that when you have integer field in DB, you do not attempt to insert
''for it. One of the most common PostgreSQL errors is "invalid input syntax for integer", and it almost always means that a module has attempted to insert zero-length string as an integer value.I don't know much about MySQL, but if the strict mode in MySQL 5 works as I think it does, using it should really fix most compatibility errors like this. Every developer should always use it.
These are fixed
We do not use REPLACE in core. database.mysql uses that (unnecessary) but that's mysql specific anyways. The integer(11) to integer is on its way, I am not sure whether we changed pver already but discussed it for sure.
IF, on the other hand is simply implemented in postgresql as a user defined function. Recently you do not even need pl/pgsql (or whatever) just plain SQL.
'%d' was cleaned out a few days ago.
--
Read my developer blog on Drupal4hu.
I still use MySQL, but I go PostgreSQL soon
I still use MySQL 4.1, but I plan to migrate to PostgreSQL soon.
--
NSK, Founder of the Wikinerds Community. See my Drupal site, the Wikinerds Portal.
Don't do it.
As someone who has gone the Postgresql route with Drupal, I strongly advise you not to do this.
You can, if you're careful
I use PostgreSQL, and have since 4.5
As other posters have said, some non-core modules don't have PostgreSQL support. In some cases all you need to do is translate the create table structures (not too difficult if you know PostgreSQL) and you're done. In other cases it is a little more difficult.
I have simply stuck to using those features that are supported under PostgreSQL, since I have 5 years experience developing PostgreSQL apps (in house for my organisation) and I have never used MySQL for any large projects.
aggregation
Having a poll in the news feed, being aggregated by a news reader which doesn't have a feature to ignore updated stories (google reader), is unfortunately very annoying. Everytime the feed is read, the new numbers on the poll indicate new content. I'm seeing this story about every third story in my feed reader.
---
http://blog.apathyant.com | http://www.brentc.com
then why don't you get a
then why don't you get a reader that does ignore updated stories?
I run ..
Mysql front ends, which link into a central postgresql back-end (shared among all sites).
I might actually set up my first proper postgresql drupal install soon.
--
The future is so Bryght, I have to wear shades.
mysql or mysqli?
I use the PHP mysql extension and will switch to mysqi as soon as the Drupal 4.7.0 upgrade is out of the way. I will use MySQL 5 with mysqli. How will Drupal handle mysql/myslqi?
petermoulding.com/web_architect
We hope that it will handle
We hope that it will handle it just fine. :)
I recommend that you get the release candidate once it becomes available and run some tests.
--
Drupal services
My Drupal services
what you think about supporting SQLite in drupal?
subj
performance problem
I have written and someone else did also an SQLite layer -- not hard at all. SQLite locks DB on writing, and this causes performance problems. Also 2.8 has some severe bugs. 3.x is much better but that's natively supported in PHP 5.1 only which is not even out yet.
Ah and someone would need to maintain that...
--
Read my developer blog on Drupal4hu.
Here is a previous discussion
http://drupal.org/node/6448
http://drupal.org/node/13192
There was another on the mailing list too.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
My site
My site http://de.castlecops.com uses the mysqli database connection layer for drupal successfully on MySQL 4.1.x. and PHP 5.0.x.
Are you sure?
Are you sure this site is Drupal? Is this pre-4.4, or heavily customized?
You have all these s=zzzzzzzzz in links.
You also have hxxp://de.castlecops.com/forum/newreply.php?s=72b56c6e321235ffb8a735446f9013f0&&do=newreply&noquote=1&t=122
And
hxxp://de.castlecops.com/forum/register.php
What is going on?
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com
It is Drupal...
...but the forum is vBulletin -as far as I can tell
Best regards,
Lennart - forsker.net
Unwillingly
I currently run MySQL, although I would much prefer to run PostgreSQL.
I've had too many problems with the instability of MySQL when running under significant load to trust it very far. MySQL is the only daemon for which I've ever had to write a watchdog cron job (apart from a dodgy terminal server authentication daemon back in the day).
Also unwilling mysql user
When I first installed a test drupal (about a month ago) I used postgres as it was claimed that it was supported.
However, I encountered many errors and bugs in the code - then when I looked through the sql file to set up all the tables I noticed that half of it was mysql code and wouldn't work anyway.
Thus my "production" (still testing) is using mysql. :-(
Having said that - I would *much* prefer to use oracle since our company database is oracle and using that would mean less dbs to support, easier backup, etc. Most of the data I want to display via drupal will be coming from oracle.
Roll on ADODB - you know you want to :)
I use MySQL 4.1.x with PHP
I use MySQL 4.1.x with PHP 4.3.x to run http://www.drunkinpublic.net and the rest of my sites.
SO SICK OF SEEING THIS
This article comes up in my feed reader every hour! Can it be pushed off the rss items yet?!
PostgreSql is my prefered database
I've ran drupal 4.4 with mysql for more than 1 year. Now I moved to drupal 4.6 with postgreSql.
Drupal, including non-core modules, supports mysql perfectly. When I tried postgresql, I met many problems and had to find pathes or done my own. I think it's a important reason for some people using mysql that they can avoid these troubles.
:)
Please keep going with progresql, thank you.
New poll
What about a poll:
What database do you WANT to use with Drupal?
If you want to use something
If you want to use something else but pgsql or mysql you bbetter start sending patches, ;)
--
Drupal services
My Drupal services
I have created a 'feature request' issue for Oracle support
Basically for the sake of completeness... at some point someone may be inspired to work on this :)
http://drupal.org/node/39260
--
puregin
Considering drupal mySQL a blocker
I am considering Drupal but since my experience with MSSQL goes back to its inception and the 40+ projects running on that server are already using MSSQL I am still wary of installing and supporting mySQL as well.
As for the politics concerning my vs ms sql I sum it up like this:
Before stored procedure support there was no way I was going to use mySQL. Who the heck wants to write dynamic sql in a hostile environment like the web? Seemed to me the only people using mySQL then was open source zealots and/or DBA hobbiest.
Now that mySQL supports stored procedures (with typed params I suppose/hope) it is at least on the table as a consideration. Now I only need a reason. Cost isn't an issue since I already own MSSQL and even if I didn't MSDE can handle a pretty good load of hundreds of simultanous users and is free as well.
So at this time the only reason for me to use mySQL is so I don't have to mod all this great free software thats available.
Its the same kind of virtous circle that benefited Microsoft, why use a different OS when there is so much software for Windows.
If MSSQL was supported I would have already installed Drupal.
Of all the software MS ever wrote MSSQL is the best of it.
please note
This thread is almost a year old.
This is Open Source software. There was once a maintainer for a MS SQL schema. Should you choose to contribute one it will be accepted. It merely needs a contributor and maintainer as does anything else in Drupal core.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
you can mix and match
Hello Lonecrow,
I have used MySQL, MSSQL, and other databases for projects from quick experiments (a few minutes) up to large scale projects for big companies. Oracle is the most difficult to use and MySQL the easiest. I can also use MySQL easily on every useful server operating system out there. For that reason I use MySQL even when creating a demonstration database for a system that will be implemented in MSSQL. That MySQL ease of installation and use is one reason why so many projects start with MySQL and never change to anything else.
I have used ASP as well as PHP and performed conversions between the two. Converting from MSSQL to MySQL is so easy that it is the easiest part of an ASP to PHP conversion, far easier than an Oracle to MySQL or Oracle to MSSQL conversion.
If you really want database independence then convert all your SQL to one of the SQL standards. MySQL supports SQL 92 and PostgreSQL supports SQL 99. PostgreSQL is harder to install on Windows and MySQL release 5 gives you most of the features of PostgreSQL, which is another reason to stick with MySQL.
Of all the software MS ever wrote, NT is the best. I know from experience of installing thousands of systems. MSSQL is a very good upgrade to the Sybase that MS purchased as the base for MSSQL but it is very hard to find someone that knows how to tune MSSQL or to diagnose problems with MSSQL.
When there is a conflict between two applications accessing tables in a shared database, the quickest solution is often to invest a couple of hours running up a Windows or Linux machine, Apache, PHP, PHPMyAdmin, and MySQL, transfer some of the tables to MySQL then run one of the applications on the MySQL machine.
Overall MySQL provides a simple database solution that works equally well in an MS environment or one of the alternative environments. You can interconnect environments with ODBC. If you are considering any change away from Microsoft software then MSSQL to MySQL is the easiest followed by ASP to PHP, then IIS to Apache and both can be performed without changing your operating system.
One question. I have used stored procedures in Oracle to make up for shortfalls in Oracle. When do you use stored procedures in MSSQL?
Peter
petermoulding.com/web_architect
PostgreSQL only
I use postgres whereever possible, and mysql only (very) grudgingly.
Mysql porting to Oracle
I use MySql now but i try to port it on Oracle
I love embedded Oracle support ;)
Ready for Testing: New Oracle Driver for Drupal
After over 1.5 years of development (since 29/11, 2005), plus number of developers contribution, and help of Drupal 6.x schema API, a new Oracle driver for Drupal 6.x is now ready for testing.
If you are interesting about this topic, please feel free to test it out, and send back your feedback, bugs, and suggestions.
Drupal 6.x LOBs patch issue: http://drupal.org/node/147947
Drupal 6.x Oracle driver issue: http://drupal.org/node/39260
----------------------------------------
What do you hope from my personal blog??