I'm writing an application which involves lots of relations between tables. Seen from a high level, my application will have to enforce lots of rules to ensure database integrity. Before I used SQLite I would have enforced all these rules in my software. But SQLite has lots of ways to do this itself, with ON CONFLICT, TRIGGERs, and stuff like that. But I don't see any real reason to use these features, and I'm concerned about how well I can document what each of them is there for.
I'm an experienced programmer and will have no problem enforcing the rules in my software. On the other hand, SQLite does some of them very neatly, with less code than I'd need in my application. On the gripping hand, if my software fails to do an operation it knows why and can generate a specific error message, whereas if SQLite hits a CONFLICT my error message would have to list all the possible reasons and let the user decide which one was the cause. Do any of you have experience with doing this ? Are there some conclusive points which will make me decide immediately that I should do it one way or the other ? I accept reasoned argument, URLs, anecdotes, or anything else relevant. By the way, the SQLite documentation is excellent but it's a little short on examples (unless there are a treasure trove of them somewhere I missed ?). How would I, for example, make SQLite refuse to delete an account if any transactions are recorded for it ? Make up your own schema for the two tables, as long at they're convincing. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
