1. SQL Server
- Posted by Craig Welch <craig at singmail.com> Nov 03, 2005
- 459 views
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
- Posted by ChrisBurch2 <crylex at freeuk.co.uk> Nov 03, 2005
- 434 views
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
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Nov 03, 2005
- 482 views
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