Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Firebird Goes Gold 30

Posted by timothy from the can-a-bird-that-heavy-fly? dept.
An Anonymous Coward writes: "A lot has happened since Borland open sourced their Interbase database. Borland has since come out with a new closed source version of Interbase, forcing the Phoenix group to fork the codebase, calling their new database Firebird. Over the past month they have come out with Firebird version 1.0 for various UNIX variants, Windows, and Mac OS X and are now working on moving the code base from C to C++. A great description of Firebird is found here. To show your support, order Firebird on CD."
This discussion has been archived. No new comments can be posted.

Firebird Goes Gold More

Firebird Goes Gold

Comments Filter:
  • I notice some stories, like this one, are posted in areas that I should be seeing on my custom slashdot homepage, but never show up unless I view the "older stuff" link. And usually they have a very low number of comments, so I'm guessing not too many other readers are seeing them either.

    What is going on?

    • Re:What is going on? (Score:3, Informative)

      by crisco ( 4669 )
      Hit your preferences page, about the 5th option down should be something called 'Collapse Sections', put a check mark in that, go to the end of the page and hit the save button. You should now see all the articles that show up in each of the sections of /. but don't get put up on the front page. And yeah, its normal for not all of them to make the front page.
    • I notice some stories, like this one, are posted in areas that I should be seeing on my custom slashdot homepage, but never show up unless I view the "older stuff" link. And usually they have a very low number of comments, so I'm guessing not too many other readers are seeing them either.
      There is a setting in your user preferences:
      "Collapse Sections (show stories from all sections, unless specifically excluded)"
      I stumbled over this setting recently and activated it, and since then I see those "invisible" stories all the time. I guess these are stories that the editors think are unimportant for most of the readers (althought these stories are sometimes far more interesting than the rest) and normaly only show up in the slashboxes of a specific section.
      I think this "feature" should be abandoned and all stories be visible by default
  • This is my first attempt at doing anything with an SQL server, I'm used to MS-Access97, so we're going off the deep end with no lifeguard. It's going to be interesting.

    So far I've got the database installed, and found I needed a tool to administer it enough to change the password, did that... now what?

    --Mike--

    • The SQL engines that I normally use come with simple programs that allow me to type SQL at the back end and look at the results. The next step should probably be to get a book on SQL (I highly recommend The Practical SQL Handbook) and use a program like that to define some tables, stuff some data into those tables, perform queries on that data, and so forth.

      Once you're there, you're probably going to want to replace those handwritten queries with a friendlier interface, so you'll be looking at developing applications that use those queries internally. However, giving specific advice about that is hard because I don't know what kinds of applications you'd be interested in doing.

    • You can't do real database work without know the standard database language. I suggest getting a copy of Melton and Simon's Understanding the New SQL. Expensive, but good.

      Also, one of the few things Access is good for (aside from producing forehead-shaped wall divots) is learning SQL. You can start out composing a query in the query-by-example form, then switch to the SQL view, tweak it there, switch back... Downside is that you will then have to unlearn the sillier features of Access's SQL implementation. Somebody wasn't paying attention in Set Theory 101!

      You can also use Access as a front end for Interbase/Firebird. Not that you should....

  • Nice compatibility with Interbase 6.01!
  • I keep saying it. He doesn't listen. Most of Slashdot's performance issues relate to its use of MySql. Listen up! MySql is just a indexed file manager with a SQL front-end. There's more to RDBMS than support a relational language! Get a real DBMS already! Give Firebird a try, or I'll tell Kathleen about the dead pelican!
    • MySQL is indeed not a "real DBMS", but that fact makes it faster, not slower. If Slashdot had a serious problem with data corruption, you'd have a point. But in terms of performance, moving to a "real DBMS" would make the situation worse.
      • Watch the categorical statements. "MySQL is faster" than other engines? Then why do people use any other engine?

        And no, the answer is not "features".

        Here's the nasty truth: for most large-scale applications, MySQL is very slow. Despite its SQL front end, MySQL is just a simple indexed file engine. Now, there are a lot of applications where such an engine is more efficient than a relational engine. That would include a lot of low-end databases of the type you see on web sites that serve a few thousand hits per day. Naturally, the implementors of those web sites find that MySQL meets their needs better than fancier software. But to generalize from that to the believe that MySQL is the fastest engine for all applications is very naive.

        I don't know of any other web site of Slashdot's scale (measured in daily hits) that uses MySQL to serve its content. (Before you start citing examples, note that Slashdot's daily hit count is in the millions.) The engine just isn't up to it. Rob gets around this by throwing hardware at the problem, and by generating static HTML files for popular content -- content that on any other high-end web site would be generated by a dynamic retrieval.

        • But to generalize from that to the believe that MySQL is the fastest engine for all applications is very naive.

          If you actually read what I wrote, you'll see that I didn't make such a general claim.

          Despite its SQL front end, MySQL is just a simple indexed file engine.

          And how do you think that imposing the additional requirements of full SQL semantics makes a database faster?

          Here's the nasty truth: for most large-scale applications, MySQL is very slow.

          Now, who is talking in vague generalities? If MySQL matches the application, it tends to do pretty well in my experience, even for large databases. Slashdot looks to me like it ought to be a pretty good match to MySQL.

          The nasty truth is that many real-world, high-performance transactional systems, scientific databases, and web sites don't use SQL or relational databases at all because they are simply too slow. Go and actually look at IBM's high-end transaction processing systems or the architectures behind major web search engines.

          • Peace! (Score:2)

            by fm6 ( 162816 )
            OK, I seem to have read too much into "MySQL is faster." You have to admit it reads like, "MySQL is the fasted database on the planet" -- something I get told a lot.

            But I hope you're not trying to argue that a simple data access technique like the one MySQL uses can scale indefinately! Just how far it can scale is a matter for someone who strong in database theory than I am. But it seems obvious to me that you'll reach the limitations pretty soon.

            Now, when you compare MySQL with more advanced DBMSs, you can't just focus on one difference like data integrity. There are a lot of differences -- query optimization, obscure techniques for speeding up file I/O, etc., etc. Nor can you blame any one of these difference for the massive overhead of running high-end DBMSs like Oracle.

            Which brings us back to the actual topic: Firebird. Which is just a fork of Interbase. Which is almost as different from Oracle as MySQL is. Which is why Interbase has an excellent reputation as an engine that supports high performance with low overhead.

            • But I hope you're not trying to argue that a simple data access technique like the one MySQL uses can scale indefinately!

              Why not? What kind of magic do you think happens when problems get big? The most scalable and efficient database applications use the simplest representations: fixed size records addressed by absolute location on a raw device. They access any record with at most one, carefully scheduled seek, with no queries, no buffer copies, and no context switch. Using any kind of additional data structure would only make them slower.

              Which is why Interbase has an excellent reputation as an engine that supports high performance with low overhead.

              That's roughly like saying that the C-shell is faster than the Bourne shell. It may be true, and someone who only knows shell programming may care. But if performance really matters, you don't write shell scripts, you program in assembly or C.

              • If you're totally ignorant of basic computer science [umbc.edu].
                • What's your point? Your link is to some basic index data structures. Index data structures are slow. Really high performance database applications can't afford the overhead of index data structures and avoid using them (which is what I was describing).

                  Besides, you don't need something of the complexity of Interbase to get B-trees or similar structures. Berkeley DB has B-trees, and so does MySQL. And the fewer features the database has, the more it can optimize its implementation of the index structures.

  • Anybody using InterBase-derivatives for anything real? I've only used the version that shipped with Delphi 1, when InterBase could barely be catogerized as a database.

    What's the status now, how does it compare to other free databases like MySQL and PostGreSQL?

    • Re:InterBase performance? (Score:3, Insightful)

      by joib ( 70841 )
      Hejsan Lasse! :)

      Disclaimer: I have used MySQL (a little) and PgSQL (a lot more) but not FB (nor IB), so I'm just repeating what I have read somewhere.

      My impression is that FB and PgSQL are quite similar. Both have multiversion cuncurrency control, ACID compliancy, stored procedures, triggers, referential integrity and a lot of other cool stuff. Both support large subsets of SQL92, outer joins, subselects etc.
      PgSQL, on one hand, is a classical unix style forking multi-process server, whereas FB has both a multi-process and a multithreaded model. The advantage of the multithreaded model is of course a shared cache, but FB:s threaded version doesn't work on multiprocessor machines. Anyway, on unix at least PgSQL uses posix (or was it sysv?) shm to get a shared cache. On the other hand, the windows version of PgSQL is a cygwin hack, whereas FB has a native win version.

      MySQL, on the other hand, does not (currently) play in the same league. Yes, with simple queries and low concurrency (albeit a common situation) it probably smokes both FB and PgSQL speedwise. IMHO MySQL suffers from limited SQL support, table level locking and lack of ACID properties. For more info check out this page [openacs.org] which describes some of the problems with MySQL in more detail (and of course there is a super-long flamewar at the end too...). Anyway, MySQL 4 (alpha) apparently supports more SQL constructs, and new tablehandlers give it row-level locking (or even multiversion concurrency control) and at least some limited ACID capabilities, so the gap between MySQL and PgSQL/FB appears to be shrinking fast..

      And then there is of course SAPDB, which appears to be very impressive according to the few people who have tried it.

      In the end, I think all of them are excellent (with some reservations towards MySQL and SAPDB). And of course they are all free (duh!). I'd say FB has better windows support than PgSQL and certainly has better delphi drivers, whereas PgSQL would be better on a multiprocessor unix/linux box.
  • For your information ,"Firebird" is also used for a Chinese Bulletin Board System called FireBird as seen in
    http://www.firebird.org.tw
  • It would have been nice for Borland to find the contributions of the open source community useful enough to stick with keeping Interbase open. But the fact is that between MySQL and PostgreSQL, there is probably not much need for yet another open source database.
  • Who cares about Borland. Soon, MS.net will be the only way to develop!!!

Slashdot Top Deals

Your own mileage may vary.

Close