1. SQL Server
I'm thinking about choice of database for an application I'm starting.
It will likely have a couple of million records.
My thought process went something like this:
1. Flat tab-delineated file, work out access myself. I've done this
in simple applications with just a few records, but it seems that
the indexing would be tedious, so my thoughts turned to:
2. Euphoria Database System (EDS). I've used this, and it seems
robust and stable. But indexed only on one field, so my thoughts
turned to:
3. Tsunami. All the write-ups seem good. Not keen on fixed field
lengths. Reading the preamble made me think that I should be using
a relational database, so my thoughts turned to:
4. euSQL
5. MySQL
6. SQLite - they all seem to have their strengths, as one would
expect. But in the process of looking at the, I realised with a
bit of a 'duh' that I have a licensed version of:
7. Microsoft's SQL Server. This is on my machine behind Goldmine,
that I use every day. I've never needed or tried to write an app
against SQL Server, so I didn't think of it until now. From a
document about it: "SQL Server has Wizards to help a novice DBA or
an end user quickly perform every day tasks. Wizards
include: Create Database, Create Index, Create Login, Create
Stored Procedures, Create View, Indexing, DTS Exporting and
Importing, Database Management (Backup/Restore), and Replication".
All very neat, and I like the backup facility (which can be
automated, as I do with the Goldmine database).
Which leads me to my question here:
It seems that I could use Matt Lewis' odbc.e API against SQL Server. But
this has an added degree of complication compared to using say SQLite.
Such as creating a User Data Source Name. Has anyone used odbc.e with
SQL Server, and if so have any implementation comments?
Anyone at all care to comment on my decision process, and if it seems
wise to concentrate on SQL Server or be well served with one of options 4-6?
Thanks,
2. Re: SQL Server
Hi
http://www.sqlite.org/whentouse.html
(In case you're wondering, this is not an 'sqlite is better than
everything else' site)
Chris
3. Re: SQL Server
Craig Welch wrote:
>
> I'm thinking about choice of database for an application I'm starting.
> It will likely have a couple of million records.
> 2. Euphoria Database System (EDS). I've used this, and it seems
> robust and stable. But indexed only on one field, so my thoughts
> turned to:
> 7. Microsoft's SQL Server. This is on my machine behind Goldmine,
> that I use every day. I've never needed or tried to write an app
> against SQL Server, so I didn't think of it until now. From a
> document about it: "SQL Server has Wizards to help a novice DBA or
> an end user quickly perform every day tasks.
> Which leads me to my question here:
>
> Has anyone used odbc.e with
> SQL Server, and if so have any implementation comments?
>
First off, it doesn't matter so much how many records your database will
hold as how many *transactions* it will need to process. If, for example,
your database will hold the population data for every small and large town
in the entire world, but will only be accessed or updated a few times a
minute, EDS will do nicely. You can also create separate index tables to
sort on multiple keys, but these will have to be maintained in your program.
If, on the other hand, you are updating or accessing your database from
multiple clients simultaneously, and have hundreds or thousands of
transactions per minute, SQL Server (if you already have it) or PostgreSQL
are better choices. MySQL is a good system, but is only suited to moderate
transaction rates.
I'm in the middle of writing an MIS database program using an existing SQL
Server machine and odbc.e. Creating the ODBC object can be done on each
workstation in the control panel, or set up using group policy (but don't
ask me how to do that). Once the object is set up, you can access it pretty
seemlessly through the wrapper. It works great, and the example program in
the library is very clear. The only concern with ODBC and SQL Server is that
odbc doesn't really exist on Linux. There have been some attempts to
create one, but nobody has been able to come up with a working Linux
odbc driver for SQL Server that I've seen.
HTH,
Michael J. Sabal
