> From: Michael Peligro <[EMAIL PROTECTED]> > > I'm also beginning to see that based on the responses to my post. Thanks to > everyone who responded. MySQL needs to mature first and integrate it with > InnoDB, plus a lot of benchmarks and load-testing before they cut it loose > for rock-solid, dependable enterprise use.
MySQL does integrate with InnoDB nicely as far as I can tell. It's just that its SQL features are still lacking. It doesn't even have subqueries yet, for crying out loud! Still, what is already there is very nice, arguably better (friendlier) than PostgreSQL, Firebird, SQL Server and even Oracle. I have the built in functions in mind mostly when I say this. > Can Firebird and PostgreSQL handle transactions with fine-granularity? > > In Progress, we can get as deep as we want in a transaction and undo the whole > thing - hundreds of modules and thousands of records, if we want. We can nest > transactions and decide what gets undone by enclosing the code block in 4GL > statements such as DO TRANSACTION ON ERROR UNDO, RETRY: > > This feature is important since we update lots of records (like sensitive > financial records, supplier accounts, copies of bank transaction records, > etc..) and the ability to undo transactions is a safety net for fail-safe > reliability and good error-handling. Maybe. You should try to research on this. I know Firebird supports 'transaction isolation levels' although I'm still not clear on what exactly this is about. > > More or less. I know that with Interbase, if you go beyond 2GB, you will > > need to span your database across multiple files. (Not sure if the 2GB > > limit is still present in the latest Firebird). Don't know about > > PostgreSQL, but 2GB or 4GB is often an OS filesystem (at least under NTFS > > and earlier Linux filesytems) imposed limit even if the DBMS can support > > larger sizes. > > It's funny how Progress database can grow beyond 2GB in NT4.0. Yeah. That's not supposed to be possible. How does it do that?!? (Or maybe NTFS' limit is 3GB or 4GB instead of 2GB?) I believe Oracle allows you to create a dedicated partition with their own(?) filesystem format presumably to go around OS filesystem limits and maybe to improve performance as well. > We'd love to span the database across multiple files in a RAID setup, > but we haven't figured out how to do it before with NT. We need to study > this filesize limit in Firebird on Linux extensively. Shouldn't the RAID setup be independent of the DBMS' view of the filesystem? > Is it safe to assume that Firebird can be spanned and RAIDed at the same time > in Linux? (There goes my awkward English again.) The way I understand it, this should present no problems. Although I have no idea wrt to the performance issues. > > Firebird is a bit less friendly than MySQL owing to its sophistication. > > But the amazing thing about it is the extremely small footprint. I believe > > it's smaller than MySQL-Max even though *it provides the full array > > of SQL features the latter sorely lacks* - everything from triggers > > to views to stored procedures. > > Views, triggers, and stored procedures are important functionalities that we > use. You could still use MySQL - if you're willing to code workarounds for the lack of these functionality. That might be a lot of work though. > What application development tool works well with Firebird, or provides a > somewhat nice and tight compatible integration with Firebird? Since Firebird > is from Borland, I presume the RAD IDE to use is Kylix3? Yes. Kylix versions of IBObjects and FIBPlus (www.devrace.com) might not be ready for 'primetime' yet (they're not on the webpages but if you contact the authors, I believe they will point you to a download link for it). The kinterbasdb Python binding for Interbase/Firebird (supporting Python DB-API 2.0) is marked as v3.x and that's what I'm currently futzing with. I'm thinking of writing a curses-based front end for a Firebird hosted database running under Slackware on a 32MB 200Mhz Pentium. Don't want to be running no X server on that machine... > In my opinion, Progress is truly a heavyweight database already, considering > that the mature database technology I'm speaking of harks back to 1998. We > haven't upgraded the database to newer versions because the old database > perfectly serves our needs. Don't forget that PostgreSQL and Interbase have also been around for a looong time already, much earlier than 1998. (Progress itself may have also been based on something older.) > But we're not closing our eyes to open-source databases and open-source > scripting languages. We'd test them extensively, and decide whether to wait > for these technology to mature, or jump ship if we see a good one. But for > now, the proprietary technology in Progress outshines open-source > alternatives on all benchmarks: reliability, ease-of-use, feature-set. Got links to these benchmarks? > Too bad the MySQL and Progress/Nusphere partnership didn't turn out fine. >From what I've been reading, it seems that Nusphere did not act in good faith. They refused to release source for their Gemini table handler (which roughly falls somewhere between BDB and InnoDB tables in terms of features/coolness). _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
