SQLite for small software
-
I'm considerind adding database capabilities to my software. First step is selecting the proper database. The database should have 0 maintenance, be light weight. I would also appreciate a single file binary database and not BDF/Paradox like ASCII files. At the moment I think SQLite could make it. Once you made a choice - especially with small companies like mine - it is difficult to switch to another one. So since I'm not a database specialist, I would appreciate advices or suggestions on other candidates, and possibly pros and cons. Thanks, Yarp http://www.senosoft.com/
-
I'm considerind adding database capabilities to my software. First step is selecting the proper database. The database should have 0 maintenance, be light weight. I would also appreciate a single file binary database and not BDF/Paradox like ASCII files. At the moment I think SQLite could make it. Once you made a choice - especially with small companies like mine - it is difficult to switch to another one. So since I'm not a database specialist, I would appreciate advices or suggestions on other candidates, and possibly pros and cons. Thanks, Yarp http://www.senosoft.com/
SQLite is a proprietary format embedded database .. that sort of works against 'switching to another one' unless, you use a database abstraction layer in between your code and the database layer. The most obvious one I can think of is ODBC, and there is an (?experimental) ODBC driver for Sqlite. You're still not off the hook with ODBC, because of SQL variations (Ie SQLite doesnt support all of the SQL-92 Standard) , but it could make it 'easier' to use ODBC There is a database abstraction layer (cant remember the name off-hand, will look it up and try and post back), that MAY (memory is a bit dim) let you select between different database 'back-ends' - my guess is you would still have to stick to fairly basic SQL unless its translated somewhere for each potential database back-end. .. but thats the approach I would use if there was any hint of having to change the database back-end .. (if it counts for anything, I use SQLite in some projects - I also use SQLite and Oracle 9i in other projects) hth, 'g' ps .. your p3DO explorer looks great - wish I knew how to do some of that stuff - not enough time .... -- modified at 2:10 Saturday 17th June, 2006
-
SQLite is a proprietary format embedded database .. that sort of works against 'switching to another one' unless, you use a database abstraction layer in between your code and the database layer. The most obvious one I can think of is ODBC, and there is an (?experimental) ODBC driver for Sqlite. You're still not off the hook with ODBC, because of SQL variations (Ie SQLite doesnt support all of the SQL-92 Standard) , but it could make it 'easier' to use ODBC There is a database abstraction layer (cant remember the name off-hand, will look it up and try and post back), that MAY (memory is a bit dim) let you select between different database 'back-ends' - my guess is you would still have to stick to fairly basic SQL unless its translated somewhere for each potential database back-end. .. but thats the approach I would use if there was any hint of having to change the database back-end .. (if it counts for anything, I use SQLite in some projects - I also use SQLite and Oracle 9i in other projects) hth, 'g' ps .. your p3DO explorer looks great - wish I knew how to do some of that stuff - not enough time .... -- modified at 2:10 Saturday 17th June, 2006
Thanks for your detailed answer Garth, Since my needs are rather basic I will most probably only use SQL basic commands. So I think I can cope with those SQLite limitations. Also although I will design it for multi-users use it'll mostly be used by single user. For the driver, yes it is a choice in itself but the thiner layer, the better. > your p3DO explorer ... - wish I knew how to do some ... - not enough time Yes it takes a lot of time, fortunately (or not ;) I'm single and I love 2D/3D graphics. This gives me the will to go ahead. Looking for the proper library/component is a hard part of the project (I made severall costly mistakes in the past). Yarp http://www.senosoft.com/
-
Thanks for your detailed answer Garth, Since my needs are rather basic I will most probably only use SQL basic commands. So I think I can cope with those SQLite limitations. Also although I will design it for multi-users use it'll mostly be used by single user. For the driver, yes it is a choice in itself but the thiner layer, the better. > your p3DO explorer ... - wish I knew how to do some ... - not enough time Yes it takes a lot of time, fortunately (or not ;) I'm single and I love 2D/3D graphics. This gives me the will to go ahead. Looking for the proper library/component is a hard part of the project (I made severall costly mistakes in the past). Yarp http://www.senosoft.com/
You can try out Firebird. It can be used both as standalone or as a full server. I think you can convert a standalone database to a server very easily. For more check http://www.firebirdsql.org/[^] -- Don't take life seriously because you can't come out of it alive. -Warren Miller (From Monty2[^] bio)
-
You can try out Firebird. It can be used both as standalone or as a full server. I think you can convert a standalone database to a server very easily. For more check http://www.firebirdsql.org/[^] -- Don't take life seriously because you can't come out of it alive. -Warren Miller (From Monty2[^] bio)
Thank you for your advice. I already used Interbase in the past, it is a good database but not light enough for what I intend to do. I would most probably choose it for professional clients running on a network (I've read SQLite is not good for transactionnal network access), but my needs are too basic even for Interbase. Note - I don't say for FireBird since I don't know it. Yarp http://www.senosoft.com/