On Tue, 2009-05-19 at 17:38 +0530, Rajen M. Parekh wrote:
Foreign key constraints can be easily achieved with sqlite using triggers. I have personally implemented 3 desktop projects using sqlite + Qt and in all cases I have used triggers to enforce foreign key constraints. And you won't need zillions of lines of code. Only a few triggers for each constraint. And even that can be automated. In fact, there already is a web script which automatically generates triggers to implement foreign key constraints by parsing the original "CREATE TABLE" statement. Sqlite allows you to mention foreign key constraints in your "create table" statement even though it does not currently implement it.
Thanks for the update. It is just that some one would need to make this happen. We want the system to be enterprise ready and some database which can handle tuns of records and do indexing in an efficient way is needed.
Using sqlite is actually a boon for creating applications for desktop use. The only shortcoming of sqlite is no support for procedures. But that can be overcome by using relevant functions within the app. In short, I feel that sqlite does a very good job. And it is very fast.
It is not the question of stored procedures (although it means a hel lot of performance boost when stored procedures are used), but the scalability is the question here.
And btw, this is not a desktop application - it is a
server.
Technically, yes. But in usage the aim appears to create a desktop application for accounting purpose. In any case, sqlite supports multiple access to its data, and even has transaction support.
Technically the aim *is* an application which *can* run on a desktop with minimum user intervention in setting up the system.
http://www.sqlite.org/faq.html#q5
I am not sure about the recent versions of Tally, but previous versions (I guess upto 5.4 or maybe even 6.3) of Tally used its own internal system to manage data. It did not use third party databases to store data. This, in my view, is the correct approach for desktop applications.
But this also prevents standardised data storage and retrival methods. Any ways that was the main aim of tally and is the case with all proprietory softwares, to create the "vendor lock-in ". So it is a highly undesirable method to store the data in some kind of standard which only we as core GK developres understand. And even if we publish the specs, I don't find any reason to create a new "GNUKhata Query Language " or some thing similar and add to the list of already available data languages.
As the lead developer I conciously took this decision so that I can answer "it is just the matter of doing this " when people as "can I prot this to mysql or ... db server?".
I hope the point is clear, else don't hesitate to ask back.
happy hacking. Krishnakant.
If you talk about scalability and enterprise level things then probably, one would need other dbms, but I personally feel that if we want users attracted to GNU/Linux then one should concentrate on creating desktop applications which simply run as is on single machines. Creating client server applications make sense in very big organisations having large number of concurrent users. Otherwise, for a desktop application, making the user install and configure other applications just to run this one application is a guranteed way of putting off the user.
Rajen.