Slashdot Mirror

Obviously, it's been a long time last time you've checked. PostgreSQL has native one-file win32-native installer already for months. For example, you can get it from here. As for Cygwin - PostgreSQL is there for years. Personally I prefer it in Cygwin: I love to have everything from sources. But some people still prefer one-file installers.

Based on changelogs here, here and here , plus your dates, I've dug up all the release dates from 1.1.1 to 9.0 (and 7.1 is just off of their web site)

1.1.1 1993-10-12
1.1.2 1994-02-05
1.2 1994-03-19
1.2.0.2 1994-04-15
1.2.0.3 1994-04-21
2.0.0 1994-07-01
2.0.1 1994-09-18
2.0.2 1994-10-18
2.1 1994-10-31
2.2 1995-03-21
2.3 1995-05-10
3.0 1995-08-24
3.1 1996-07-03
3.2 1997-02-17 (the first distro I ever used)
3.3 1997-07-11
3.4 1997-10-14
3.5 1998-06-09
3.6 1998-10-28
3.9 1999-03-10
4.0 1999-03-17
7.0 1999-11-02
7.1 2000-06-22
8.0 2001-07-01
8.1 2002-06-18
9.0 2003-03-19

My only complaint about PG is lack of replication

On Aug 28, there was a press release regarding the eRServer on the PostgreSQL website (link here). Project page for eRServer is here. Haven't checked it out yet though.

My only complaint about PG is lack of replication

On Aug 28, there was a press release regarding the eRServer on the PostgreSQL website (link here). Project page for eRServer is here. Haven't checked it out yet though.

But if you care about your data so much that you are seriously going into replicated systems, the couple of most popular free packages at least aren't there yet even in basic ACID reliability.

What are you talking about? PostgreSQL has supported ACID reliability for years.

Plus, PostgreSQL also now supports replication, the same as the one that PostgreSQL, INC. has been selling as an add-on for years (they finally opensourced it).

Another database that I would check out is SAPdb. SAP originally created it to be a competitor to Oracle, so that their customers wouldn't have to buy Oracle databases (read: pretty complicated setup, but worth it). But now they've opensourced it too, and as far as I know, it supports replication. And in the next release when MySQL takes over (Q4 2003, it'll be renamed MaxDB, and MySQL will be working on the code as well as SAP), it will have a proxy available so that you can just use MySQL database drivers to access it.

But if you care about your data so much that you are seriously going into replicated systems, the couple of most popular free packages at least aren't there yet even in basic ACID reliability.

What are you talking about? PostgreSQL has supported ACID reliability for years.

Plus, PostgreSQL also now supports replication, the same as the one that PostgreSQL, INC. has been selling as an add-on for years (they finally opensourced it).

Another database that I would check out is SAPdb. SAP originally created it to be a competitor to Oracle, so that their customers wouldn't have to buy Oracle databases (read: pretty complicated setup, but worth it). But now they've opensourced it too, and as far as I know, it supports replication. And in the next release when MySQL takes over (Q4 2003, it'll be renamed MaxDB, and MySQL will be working on the code as well as SAP), it will have a proxy available so that you can just use MySQL database drivers to access it.

Agreed. Firebird (here) and PostgreSQL(here) both do. And it works. InnoDB in mysql tries really hard, but it's behind, and it slows down MySQL (compared to ISAM/VSAM) enough you might as well use another database that, at the same speed, has more features.

The press release of ER Server becoming open source is quite informative (karma?) as well.

Marc of PostgreSQL Inc's an incredible resource on the postgresql mailinglists too; and PostgreSQL Inc has a really cool policy that allowed them to do donate their code to the community that way:

From their release: " "DATELINE FRIDAY, DECEMBER 15, 2000 Open Source vs. Proprietary: We advocate Open Source, BSD style :) We will consider and develop short term (up to 24 month) proprietary applications and solutions where there is a strong business and intellectual property case to be made. *All" proprietary developments that we are involved in *will* become open source within two years of implementation, without exception." ".

Also cool, they provide hosting http://www.pgsql.com/hosting/ which donates "25% of all profit from these services ... directly back into the PostgreSQL Project. "

Ron

I'm not affiliated with them in any way, just appreciative of Marc's contributions on the mailingslists and to postgresql as well.

Recently announced on the PostgreSQL website is commercially developed free and open replication for PostgreSQL. erserver is available for download. It is single master, many slave replication only.

Recently announced on the PostgreSQL website is commercially developed free and open replication for PostgreSQL. erserver is available for download. It is single master, many slave replication only.

PostgreSQL has released their replication technology under an open source licence.

Posted by Cliff on Thursday September 11, @04:45PM
from the prime-time-league-contenders-yet? dept.
grugruto asks: "A lot of open source solutions are available to scale web sites with clusters but what about databases? I can't afford an Oracle RAC license but can I have something more reliable and fault tolerant than my single Postgres box? I have seen this recent article that looks promising for open source solutions. Do anyone have experiences with clusters of MySQL , Postgres-R, C-JDBC or other solutions? How does it compare to commercial products?"

Two options I haven't seen anyone mention yet are PostgreSQL eRServer 1.0+ (see PostgreSQL news item "PostgreSQL now has working, tested, scalable replication!" from August 28, 2003 or a lengthier press posting "PostgreSQL, Inc. Releases Open Source Replication Version") and Backplane.

eRServer has been in development for over two years, is used in production settings and is released under a BSD license (as with PostgreSQL). It uses a single master/multiple slave asynchronous replication scheme. There are cautions in the release that replication may be difficult to setup.

Backplane seems to be particularly well-suited to clustering data quickly across a WAN. A quote may explain it better:

The Backplane Open Source Database is a replicated, transactional, fault-tolerant relational database core. Currently supported on Linux and FreeBSD, Backplane is designed to run on a large number of small servers rather than a small number of large servers. With Backplane, it is possible to spread the database nodes widely, allowing database operations to work efficiently over WAN latencies while maintaining full transactional coherency across the entire replication group.

Backplane's native quorum-based replication makes it easy to increase the database capacity (by simply adding a new node), re-synch a crashed server, or take down multiple nodes for maintenance (such as an entire co-location facility) - all without affecting the database availability.

I haven't used either yet, but you may wish to give them a look.

Two options I haven't seen anyone mention yet are PostgreSQL eRServer 1.0+ (see PostgreSQL news item "PostgreSQL now has working, tested, scalable replication!" from August 28, 2003 or a lengthier press posting "PostgreSQL, Inc. Releases Open Source Replication Version") and Backplane.

eRServer has been in development for over two years, is used in production settings and is released under a BSD license (as with PostgreSQL). It uses a single master/multiple slave asynchronous replication scheme. There are cautions in the release that replication may be difficult to setup.

Backplane seems to be particularly well-suited to clustering data quickly across a WAN. A quote may explain it better:

The Backplane Open Source Database is a replicated, transactional, fault-tolerant relational database core. Currently supported on Linux and FreeBSD, Backplane is designed to run on a large number of small servers rather than a small number of large servers. With Backplane, it is possible to spread the database nodes widely, allowing database operations to work efficiently over WAN latencies while maintaining full transactional coherency across the entire replication group.

Backplane's native quorum-based replication makes it easy to increase the database capacity (by simply adding a new node), re-synch a crashed server, or take down multiple nodes for maintenance (such as an entire co-location facility) - all without affecting the database availability.

I haven't used either yet, but you may wish to give them a look.

Another hard bit is that the Postgres replication doesn't support sequences - see the details in the aptly named "Things to Remember" section of the installation documentation.

So if your master fails, presumably you have to recreate the sequences starting at a number high enough to avoid conflicting numbers before switching over to a slave. Seems like this could be a problem.

Nonetheless, Postgres is cruising away on RubyForge; 300,000 records and counting...

And don't forget you have to vacuum postgresql databases regularly.

http://www.postgresql.org/docs/7.3/interactive/rou tine-vacuuming.html

pgsql-bugs ( at ) postgresql ( dot ) org writes:
> The problem occurs for new data types:
> When pg_dump is called, sometimes the CREATE TYPE is dumped before
> input/output functions are dumped. This makes a restore impossible.

I believe this was fixed about two weeks ago. Are you sure you are
using 7.1 final release, not some beta version?

Is this what you mean by archive log mode? If so, then PostgreSQL has it. :)

Ever heard of InnoDB? MySQL lets you choose -- on a table-by-table basis -- exactly what parts of your application need to support transactions, foreign keys, etc.

Want to do hot backups? Then all of your tables must be transaction-aware InnoDB tables (and you have to pay for the priviledge of course). Ever perform multi-row inserts? All of the affected tables should be transaction-aware InnoDB tables. If any of your data relates to each other (*cough* relational database *cough*), you need foreign keys. Here come those InnoDB tables again. Got multiple clients modifying the data at the same time? InnoDB again.

So basically what you are saying is that InnoDB tables should be used unless the table in question has no data interaction whatsoever with any other table, should only ever have one-row-at-a-time inserts, single-user access, etc. So...ummm...why would anyone use non-InnoDB tables?

Odd, neither Slashdot nor Yahoo! Finance seem to be having corruption problems...

I don't browse Yahoo Finance so I can't comment on that site or the scope of MySQL's use. As far as Slashdot...ummmm... Are you kidding!?! You are using Slashdot as a metric for the reliability of MySQL? Slashdot is your example of 24/7 uptime and consistency? The site that's regularly down and relies on static renderings of their site to avoid advertising the outages: this is one of your great examples?

I must say that I greatly enjoyed InnoDB's benchmark page. The comparison in E-Week is conveniently listed next to the PostgreSQL comparison giving the impression that E-Week also prefers MySQL over PostgreSQL even though PostgreSQL wasn't in the review. Nice marketing indeed. That aside, I also like the PostgreSQL comparison section: only two years old after all. Neither package has changed substantially in two years have they? <sarcasm>And sure, I could be persuaded that the one test query is indicative of all normal queries one would encounter in normal database operation.</sarcasm> Could it be that perhaps a certain group went hunting for items that InnoDB was markedly better at and avoided the items in which it was weaker. Naw. Couldn't be.

And this part I love the best: not only was the hardware the same, but the tuning techniques were identical. 24MB shared memory buffers. That's it on a 512MB test server with two tables of 100,000 rows. Hunh? No, that doesn't sound like they tuned MySQL overall to the detriment of PostgreSQL. How well do you think MySQL+InnoDB would fare if the app tunings were done with PostgreSQL in mind and just mapped the same settings to MySQL+InnoDB?

Note: The shared buffer setting has little to do with the overall memory usage in a working system (and even less in this benchmark). Why? After shared buffers are filled up, the OS will start to aggressively cache filesystem access (like for example, the ever-accessed database tables). MySQL is written with this situation in mind. PostgreSQL depends more heavily on the shared buffers setting (among others). If both DBs are using all available memory -- which is likely when querying a couple of 100K-row tables -- which database do you think will perform much better with the artificial constraint of a 24MB shared buffer?

And don't start with the "harder to configure" crap. This wasn't an out-of-the-box install of MySQL+InnoDB here. Someone specially configured the 24MB buffer. It took as much effort as it would to properly configure PostgreSQL. There is a wealth of information about tuning PostgreSQL for hardware, for good database organization techniques that work for more than just PostgreSQL, and of course the main PostgreSQL technical document site. (All of this was found in less than two minutes

Ever heard of InnoDB? MySQL lets you choose -- on a table-by-table basis -- exactly what parts of your application need to support transactions, foreign keys, etc.

Want to do hot backups? Then all of your tables must be transaction-aware InnoDB tables (and you have to pay for the priviledge of course). Ever perform multi-row inserts? All of the affected tables should be transaction-aware InnoDB tables. If any of your data relates to each other (*cough* relational database *cough*), you need foreign keys. Here come those InnoDB tables again. Got multiple clients modifying the data at the same time? InnoDB again.

So basically what you are saying is that InnoDB tables should be used unless the table in question has no data interaction whatsoever with any other table, should only ever have one-row-at-a-time inserts, single-user access, etc. So...ummm...why would anyone use non-InnoDB tables?

Odd, neither Slashdot nor Yahoo! Finance seem to be having corruption problems...

I don't browse Yahoo Finance so I can't comment on that site or the scope of MySQL's use. As far as Slashdot...ummmm... Are you kidding!?! You are using Slashdot as a metric for the reliability of MySQL? Slashdot is your example of 24/7 uptime and consistency? The site that's regularly down and relies on static renderings of their site to avoid advertising the outages: this is one of your great examples?

I must say that I greatly enjoyed InnoDB's benchmark page. The comparison in E-Week is conveniently listed next to the PostgreSQL comparison giving the impression that E-Week also prefers MySQL over PostgreSQL even though PostgreSQL wasn't in the review. Nice marketing indeed. That aside, I also like the PostgreSQL comparison section: only two years old after all. Neither package has changed substantially in two years have they? <sarcasm>And sure, I could be persuaded that the one test query is indicative of all normal queries one would encounter in normal database operation.</sarcasm> Could it be that perhaps a certain group went hunting for items that InnoDB was markedly better at and avoided the items in which it was weaker. Naw. Couldn't be.

And this part I love the best: not only was the hardware the same, but the tuning techniques were identical. 24MB shared memory buffers. That's it on a 512MB test server with two tables of 100,000 rows. Hunh? No, that doesn't sound like they tuned MySQL overall to the detriment of PostgreSQL. How well do you think MySQL+InnoDB would fare if the app tunings were done with PostgreSQL in mind and just mapped the same settings to MySQL+InnoDB?

Note: The shared buffer setting has little to do with the overall memory usage in a working system (and even less in this benchmark). Why? After shared buffers are filled up, the OS will start to aggressively cache filesystem access (like for example, the ever-accessed database tables). MySQL is written with this situation in mind. PostgreSQL depends more heavily on the shared buffers setting (among others). If both DBs are using all available memory -- which is likely when querying a couple of 100K-row tables -- which database do you think will perform much better with the artificial constraint of a 24MB shared buffer?

And don't start with the "harder to configure" crap. This wasn't an out-of-the-box install of MySQL+InnoDB here. Someone specially configured the 24MB buffer. It took as much effort as it would to properly configure PostgreSQL. There is a wealth of information about tuning PostgreSQL for hardware, for good database organization techniques that work for more than just PostgreSQL, and of course the main PostgreSQL technical document site. (All of this was found in less than two minutes

The Postgres-R effort is pretty slick, and could widen the gulf between PostgreSQL and that little Swedish wind-up toy whose name escapes me.

Not functional yet, but heh, every project's got to start somewhere. </shameless plug>

pgAdmin II is somewhat similar.

And pgAdmin III just reached beta and is purported to be quite a bit better (than II).

pgAdmin II is somewhat similar.

And pgAdmin III just reached beta and is purported to be quite a bit better (than II).

Oh, I should also point out, that selecting across databases/servers is listed in their urgent features in the postgresql todo list:

http://developer.postgresql.org/todo.php

If you want to bring it into Postgres, here or here

Yes, as opposed to other (non-commercially produced I guess) software where the support is non-existent (you know where the source is, there's comments too, maybe).

I've had "problems" with three or four open source software products. I put scare quotes around "problems" because in most cases my "problems" amounted to feature requests.

In each case, the "problem" was resolved with an email to the programmer.

I noticed some example SQL in the postgresql online manual had some minor inaccuracies. I sent an email with corrections, the corrections were incorporated in the manual, I was credited. End of problem.

CDex, an excellent MS-Windows CD ripper, had some problems incorporating extremly long ID3 tags into ripped MP3s. I emailed the programmer, Albert Faber, and in a matter of a few days, a fixed version was available for download. End of problem.

SciTE, the best programmer's editor I've found to date, didn't respond correctly to my mouse wheel settings. I emailed the programmer, Neil Hodgson, and (since I had access to the source) indicated some lines of code I thought responsible. Mr. Hodgson went so far as to download updated versions of the MS drivers to his own machine, and got back to me in about four hours -- despite a nearly 12 hour difference in our time zones. I was able to compile a private build with a fix, and the programmer's fix was available a week or so later in the standard build. End of problem.

MP3BookHelper, a truly phenomenal ID3 tagger, had no problems, per se, but I wanted additional features. Over the course of several months, the programmer, Vlad Skarzhevskyy, incorporated all but one of several features I asked for, usually producing a beta within 24 to 48 hours of the request. (The one feature rejected involved a user interface default value; Vlad correctly decided my proposal was at odds with MP3BookHelper's user interface standards.) No problems.

In two of these cases, I was able to look at the code myself and figure out, at least in general terms, where the problem was. In the other two cases I could have done so, but didn't need to -- but felt empowered knowing that I could assist in fixing the problem myself.

In all cases, I made a point of thanking the programmers for their hard work and quality products, and of asking for, rather than demanding, a fix, while giving what I hoped were useful clues as to the origin of the problem. And in all cases I got what I wanted far faster, and with far less frustration, than any tech support line could provide.

Please let me know what closed source software gives this sort of problem resolution, and how much the support contract is.

The problem with postgresql is that number one it does not scale worth a shit. Number two it cannot be kept online 24/7 that in itself is some major faults.

One more thing: if you're having stability problems with the database and you're running 7.3 or later, the PostgreSQL developers will be very interested in helping you track down the problem and fix it. They take stability issues very seriously (but don't really have the manpower to fix versions earlier than the 7.3 series).

Try subscribing to the PostgreSQL Hackers mailing list and post the symptoms of the problems you're experiencing there.

Similarly, for performance issues, you should try subscribing to the PostgreSQL Performance mailing list and describe your difficulties there. If they can't help you then (and only then) try asking the guys on the Hackers list.

I've found the PostgreSQL developers to be extremely responsive, helpful, friendly, and extremely capable in dealing with PostgreSQL issues of various kinds, and they all seem very interested in doing the right thing for the community. I haven't seen a better example of the open source ethos in action.

The problem with postgresql is that number one it does not scale worth a shit. Number two it cannot be kept online 24/7 that in itself is some major faults.

One more thing: if you're having stability problems with the database and you're running 7.3 or later, the PostgreSQL developers will be very interested in helping you track down the problem and fix it. They take stability issues very seriously (but don't really have the manpower to fix versions earlier than the 7.3 series).

Try subscribing to the PostgreSQL Hackers mailing list and post the symptoms of the problems you're experiencing there.

Similarly, for performance issues, you should try subscribing to the PostgreSQL Performance mailing list and describe your difficulties there. If they can't help you then (and only then) try asking the guys on the Hackers list.

I've found the PostgreSQL developers to be extremely responsive, helpful, friendly, and extremely capable in dealing with PostgreSQL issues of various kinds, and they all seem very interested in doing the right thing for the community. I haven't seen a better example of the open source ethos in action.

Because pretty much the main drawback of Java is that it severly limits which platforms you can distribute to, ironically.

The only other option is distributing a 50 meg JVM with every app

and increasing support costs by having to walk people through tedious installation procedures, for the JVM and your app.

If you can compile a native binary, you can distribute it to any binary compatible platform, regardless of what other software they have installed.

You don't have to explain CLASSPATH to your users.

You don't have to explain why they can't type "java filename.class", but instead must type "java filename".

GCJ is the only hope Java has of actually being more than an acedemic curiosity, and "something that Sun used for a few apps".

Are you even aware of the number of web sites exist whose server code is completely written in Java? Most likely you visitied a couple before you came here today.

Seems someone around here is a MySQL fan. Modded parent up, and all the replies down. Hmm... Maybe it's time to introduce Slashdot to a real database?

That someone would implement Pervasive. They'd better use PostgreSQL instead of a Pervasive Database...

What database are you going to recommend that allows you to embed C# (C++, whatever) programs in the database itself?

What database are you going to recommend that allows you to embed C# (C++, whatever) programs in the database itself?

With PostgreSQL, you can write triggers (and other functions including aggregates) in C, Tcl, Perl, Python and Ruby (see http://www.au.postgresql.org/features.html)

While I think, too, that triggers should not normally call applications not directly related to the database, it can be helpful when you can write a trigger in a language like C and are not bound to SQL (or pl/pgSQL / Transact-SQL, respectively).

To be fair, I'm young as well (I'm 20). Minus a year for college, I've been working as a programmer at my company since the summer of 2000 (with a lot of recreational programming before that).

For the last year, I've been working as a "Software Analyst". I get bug reports that our setup folks can't solve and I solve them. This often requires a lot of code hunting. We've got everything from extremely junky Fortran 77 (no whitespace, no variable names over 6 characters -- and Fortran at that) for our legacy app, and some CGI programs written in spaghetti-code C (with a good mix of HTML templating and javascript thrown in)! Even better, this all runs on HP-UX. Needless to say, I get plenty of practice fielding bad code and weird issues. =)

Our development team is comprised of 12 developers total, and only in the last 4 years has it grown past a four man team. The company is now around 50 heads total, and a QA department is in sight (the Software Analysts will eventually be QA).

Anyway, our newer products are all based on open source tools. PostgreSQL, Apache, Linux, Perl, Mason, ORBit, etc. The source code, mailing lists, IRC, etc. and the open attitude have made things a breeze, not to mention these tools have saved us a very large sum of money in licensing costs.

This is quite possibly the exception to the rule, I have no problem admitting that. Somehow, though, from what I hear of other companies, this isn't all too uncommon.

Cheers

I agree very much with Randolpho's post. Ditch PHP if you really want an elegent architecture. If you really need to stick with PHP, try out Midgard. Otherwise, you really ought to at least look at the alternatives. Zope and OpenACS are probably the best open source web application systems/environments/architectures, whatever you want to call it. I prefer OpenACS (there's just something about using a system that was built primarily by highly intelligent MIT and CalTech alumni...).

OpenACS is based on AOLServer (probably the best, and first application-oriented web server out there, which was GPL'd by AOL thanks to Phil Greenspun's nagging. it's multi-threaded, it has database pooling, a healthy set of modules/plugins, and a wonderful community.), Tcl (you'll get used to it, really ;), and either Oracle or PostgreSQL. Thought it was designed for use with Oracle, and was ported to PostgreSQL, the architecture in OpenACS permits you to easily swap in support for other databases. Though, you'd have an extremely tough time getting it to work in MySQL as it relies on numerous high-end and complex relational databases features, most of which MySQL does not support.

OpenACS is highly modular, built entirely out of smaller packages, with its own package management system. There is a core package, the ACS Kernel, ACS Tcl (which contains most of the utility code, etc.), and there are various packages built on top of that which provide both specific application functionality, but also services that other packages can use. The documentation is built into the code and is available online in every OpenACS installation. Higher up packages include web page creation, bulletin board systems, blogging, content management, etc. You can "mount" these packages at various locations in the site map for your web site / application. E.g., you could mount an instance of the bulletin board at mysite.com/forum, and add a second one at mysite.com/techsupport. You can create subsites, such as mysite.com/internal/. There is an extensive and incredibly powerful permissions system so you can completely control access to every part of your system. There is also a built-in templating system which provides a simple separation between logic and display code, as well as theming capabilities.

I'm sure there's a lot that I've neglected to mention here. But I think you can get the point. OpenACS is a very mature platform that's be in development and production for many years now (hell, take a look at what Ars Digita was able to accomplish, they were making millions selling this system, and they gave the code away for free under the GPL). Don't take my word for it, go to the website and read about it. The only drawback to it that I see is that it does have a high learning curve. It took me a few months of reading and experimenting with it to really understand how the system works, but it's definitely worth it. There are a few hosting providers out there (Acorn Hosting and Zill.net) that offer affordable hosting packages, but it's also easy to setup your own server. OpenACS also has the ability to run multiple server boxes in a load balanced environment, so if you need to scale out, you can. Oh yeah, this is also a descendant of the same ACS system that RedHat's Enterprise Applications are descended from (RedHat got that technology when they bought the remains of ArsDigita.

If you're just starting in web development, don't use MySQL unless you have absolutely no choice. It will hurt you in long term.

When you first start out, you're happy that you can put data in and pull it back out. Then you find that your data gets inconsistent for some reason. To stop this happening, database designers put constraints on the data, and use transactions. If the job is done properly, it shouldn't be possible to insert inconsistent data, like a company address that doesn't belong to a company.

Unfortunately, if you chose to use MySQL at the beginning, you're now stuffed because it doesn't provide these features. What's worse, its SQL is rather non-standard, so you're going to have a problem moving to anything else. I know that people will think I'm trolling for Postgres, but I'm not really. Use any database that supports this type of feature. There are two other open source databases which are worth a look: Firebird and SAP DB.

You might want to try an open-source relational database engine like PostGreSQL

This means, of course, you'll have to create your own schemata for logging version control and records added, but versioning additions to the database -- and user/connect information -- can be tracked with a combination of triggers and timestamps in a separate table. These are fairly standard techniques in generating an audit trail for tracking relational database changes and enforcing data integrity constraints. While the syntax varies from database engine to database engine--PostGreSQL is a good (free) place to start, and if the spirit moves you (or if the DB becomes too large) the syntax differences do not preclude your moving to, say, a development edition of IBM's DB2 UDB or even (aack!) Oracle. All three run rather nicely under SuSE Linux, and are said to run quite nicely under RedHat, as well.

It probably wouldn't harm you at all to develop this database with a relational database, and test it under different engines-- in fact, it would likely make you highly employable in the very near future.

As far as SQL Server goes, we rely heavily on stored procedures so the availability of freebies is moot for the time being.

Just an FYI: PostgreSQL has stored procedures with many available languages.

Face it: if Ellison and his buddies hadn't bought congress to get the H-1b program, most of the folks reading this would be in a far better economic position. For that matter if McNealy's co-religionist Greenspan(McNealy and Greenspan are both Ayn Rand fans) were consistent in his policies, instead of playing games that centralize assets you'd be a lot better off.

There would be a slump right now even without H-1b, but instead of 500,000 unemployed engineers, we might be looking at 50,000 or so-it that.

There are still a lot of high leverage areas in software: embedded systems, bioinformatics, robotics. What isn't clear to me if dinosaurs like Oracle,Microsoft, Sun really should be playing any role in the new software business. I say that we just Open Source all the technology of these companies-starting with Oracle.

JBOSS is a decent application server that completed head to head with Oracle Application Server. Postgres can be made better than Oracle(big missing feature is replication which is coming along fast). The accounting packages Oracle sells can be replaced by stuff that evolves from stuff like SQL Ledger. All in all, I think Oracle will be dead before Microsoft. Good Riddance.

The itch is there and people are scratching away. No idea how long it will take for it to be incorporated into a stable release though.

Your problem wouldn't be solved with the product mentioned in the story. However, because you are using MS SQL Server, this is really easy. You just need to get the postgres ODBC Driver, and setup a Linked Server on the MS box.

Check out This page for the postgresql ODBC Driver.

You should also look at the linked servers documentation in SQL Server Books Online (under sp_addlinkedserver) as well as the interface in enterprise manager (security -> linked servers)

As I was searching a bit, I see that people have had trouble using the server.database.owner.object syntax, however using the SQL Server OpenQuery(servername, query) function seems to work, and will allow you to control the exact SQL Statement sent to postgres.

The people running the site need to read their own site (to get rid of dupes) and need to run it on a real database.

Sigh...

Dude, use pgAdmin II, it has a module to migrate data from Access (97, 2K, XP) and MSSQL. I tried it with a relatively large (40 tables) Access file, and it worked like a charm, autonumber->serial and all.

See here:

Thus, we have created an integer column and arranged for its default values to be assigned from a sequence generator.

Perhaps this is (-1, Offtopic), but why suggest SQL Server with an Access front end, when you can suggest an Open Source/Free server, such as PostgreSQL, or MySQL, and an Access front end?

I've never tried it myself, but I've heard that PostgreSQL can be an ODBC datasource on Windows machines.

If you've already got Access, and you already have a viable data structure and forms/reports that work with it, you should be able to move the data to Postgres, change the tables in Access to ODBC links, and pretend like nothing changed....

Of course, I've never done any of this, so YMMV

Ian

MySQL is not robust. I mean, for crying out loud, it only got transactions fairly recently IIRC.

Umm, you've heard of PostgreSQL, right?

It's free, and is a much more complete SQL database than MySQL.

Mr Ellison stated, that the free and open Postgresql will render the expensive and clumsy Oracle database obsolete by 2005.

Attention, content-management hackers. MySQL appeals, because it's open-source, it's easy to set up, and it handles very simple queries quickly. THESE ARE ITS ONLY VIRTUES . Once your web site starts getting traffic, you have to start looking at a real DBMS that optimizes complex queries and scales worth a damn. Here's one, and another, and yet another.

1. Docs here. Everything you need is there. Install is straightforward in most distros, and very simple to do from source if you have the inclination to do it.

2. Wrong assumption. You can do whatever maintenance tasks you want without stopping the db. It's been like that since at least 7.0.

3. Nice point, if it affects you. Postgresql isn't native windows yet (it's in beta stage). It runs on all other unices, however...

4. Plenty of those for pg. It's not a problem.

5. This is a crying shame, because if apps used SQL'92 you'd be free to choose database. If an app requires MySQL, then you *need* MySQL, and the whole RDBMS choice problem can't be placed.