Subject | Re: Firebird, ODBC, web access and various beginner questions |
---|---|
Author | federonline |
Post date | 2007-09-18T17:24:15Z |
Added my comments below.
Kurt.
ODBC/ADO/etc adds quite a bit of overhead, but if your application is
trim enough, it shouldn't matter.
never had an issue. The Firebird/Interbase functions are all ready in
PHP and only need to be configured.
Windows. Classic spawns a new executable for each request while
SuperServer spawns threads. SS will be better for managing resources
on Windows systems. Classic is the old UNIX fork methodology...
purge that data regularly after a couple days. Our DBs run from
50-200M. We run on a 1.0 GHz Via processor with 512M RAM and have
never had a single performance related issue. Understand that there
are VERY few applications/services running on our system; it is
basically Windows Embedded.
SCSI so we can use a pizza box instead of the small footprint systems
we have now.
Kurt.
> --- In firebird-support@yahoogroups.com, Thomas Løcke wrote:<SNIP>
>
>I've had no issues with the ODBC Drivers for Firebird. Using
> I've thought about moving the three databases to a new multicore
> Linux server with Firebird installed. I would then convert the two
> Microsoft Access databases to Firebird and still access them using
> ODBC.
>
> My questions are:
>
> Is the Firebird ODBC driver stable? I've noticed the latest versions
> are considered BETA, and the non-BETA versions are quite old. Which
> one should I opt for?
ODBC/ADO/etc adds quite a bit of overhead, but if your application is
trim enough, it shouldn't matter.
> Is Firebird suitable for web access? I will be accessing thePHP on Apache is what we use to access our DB. It is solid and we've
> database from a PHP powered web application situated on a dedicated
> web server (Apache). The current solution where I access the
> Microsoft Access database using ODBC is by no means fast, so I'm
> not spoiled.
never had an issue. The Firebird/Interbase functions are all ready in
PHP and only need to be configured.
> Classic or Super? I've read the papers on the subject, and it seemsOthers can answer this better than I can, but I use Classic even on
> to me that I should go for Classic, seeing as I would like to fully
> utilize a multicore system. Is this assumption correct?
Windows. Classic spawns a new executable for each request while
SuperServer spawns threads. SS will be better for managing resources
on Windows systems. Classic is the old UNIX fork methodology...
> How important is RAM? The databases aren't very large (a few hundredNot necessarily. Our applications acquire time sensitive data and
> megs total). On the Windows server it seems the Firebird instance
> never grows beyond 25-30 MB. I know from a few MySQL servers I run
> that RAM is God. The more the better. It seems this might not be the
> case for Firebird?
purge that data regularly after a couple days. Our DBs run from
50-200M. We run on a 1.0 GHz Via processor with 512M RAM and have
never had a single performance related issue. Understand that there
are VERY few applications/services running on our system; it is
basically Windows Embedded.
> How important is harddrive speed? IDE, SATA, SCSI?We use 7200 RPM disks IDE...no problems. We're scaling and going to
SCSI so we can use a pizza box instead of the small footprint systems
we have now.
> Intel or AMD? I personally have no preference, except I tend toNo opinion here.
> cheer for the little guy. :o)
> OS suggestions? I plan on using Slackware, as all my other serversOur migration path is Ubuntu.
> are running Slack (except of course for the one Windows server
> discussed above).