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,
|
Not Categorized, Please Help
|
|
