> I'm interested in why you ended up with Postgres rather than MySql or > Firebird. Was it an easy decision or a close call? >
Well, let's see. I know you did not ask why not M$ SQL Server or Oracle, so I assume you are also trying to avoid some of the things I wanted to avoid - $$$ and/or dependence on running on a M$ platform and dealing with M$ planned obsolescence (or their free SQL Server versions that have scaling limitations of their own). So you have robbed me of an opportunity to bash on M$ a bit for my purposes <g>. That is okay, let's get on with it... MySQL kicks ass, but it also has a dual license, and I was concerned about any potential fees either I or my clients would incur were I to deploy a MySQL database on their Server(s) for commercial use, with me not being willing to release my Source Code into the public domain. I am not sure how much the license fee is for commercial use of MySQL when the Source Code is kept private, but I think it is $400/Server annually. Most of my clients are Auto Dealers, and even something for free is too much to pay (they really do run on very tight margins). An additional $400/year would be painful to explain, especially when they have had VFP for free for so many years from me. They would not be wanting to hear all the Geek Speak re: why I had to migrate for any one of several reasons (scalability, built in security, performance over a thin net connection, hot backups, Cross-Platform capable...). Firebird looked promising, as it is totally Open Source, and has some pretty solid legacy roots. But I found the documentation was a bit light as compared to MySql and PostgreSQL (2 years ago, may 3). I do know of one company that uses Firebird, and their app has terrible performance with any kind of fairly large table sizes. Of course, that is totally due to their design, where they take all the Firebird tables from the server and pull them to the local PC to cache all records (for faster performance). This is done both at startup and any time a locally cached cursor is hit, to make certain all local records are up to date from the server! It is not Firebird that causes the large delay in lighting up and running the application. I know it is just a silly assed and poor design by the developers. But, it still left a bad taste in my mouth, however unfair that may have been. I was intrigued by the punchy performance offered by PostgreSQL, and the large amount of information available at the local bookstores. The reference material available is pretty much on par with the Big Boys. It has been around in its current and predecessor forms for a long time, and is rock solid. It is totally open source, free to use without any license fees, and Cross-Platform capable. So, I picked up a few books on PostgreSQL (I also have "The First Official" Firebird Book, some MySQL books, plenty of MS SQL and Oracle books from prior projects). I never looked back. I also considered the fact that Dabo is able to connect to PostgreSQL (as well as MySQL and others), so once I begin to migrate to that development environment my investment in learning PostgreSQL will not be wasted. In short, if I had to prepare to move from a VFP back end to a "real RDBMS" in order to get huge scalability, great performance over thin-net connections, built in security, Cross-Platform capability, Hot Backups and no license fees, I wanted to make a single move. I asked a lot of my compadres (to include ProFox members) their opinions and experiences. As good as MySQL was, it was the totally free part with PostgreSQL that won the day. Firebird just did not have enough documentation for my comfort, and I hardly know anyone who has used it. PostgreSQL just flat out feels more comfortable to me, and has no inherent deficiencies that would impact me. And, thus far it is behaving great with a VFP front end. I hope that is helpful. Good luck in your apparent impending cut-over. Gil > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Brian Abbott > Sent: Monday, March 24, 2008 3:28 AM > To: [EMAIL PROTECTED] > Subject: Re: VFP and PostgreSQL used to process FTC DoNotCall updates > > > Gil Hale wrote: > > Well, it finally happened. The source data DoNotCall files I > download from > > the FTC monthly for clients finally pushed over the 2Gb file > size limit for > > the Area Codes used by my clients! Luckily I saw this freight > train coming > > about 2 or 3 years ago, and began to evaluate various SQL > database solutions > > Hi Gil > > I'm interested in why you ended up with Postgres rather than MySql or > Firebird. Was it an easy decision or a close call? > > -- > Cheers > > ============ > Brian Abbott > ============ > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
