Re: [sqlite] suggesiton needed for using SQL lite in a situation
On Thu, 22 Jun 2006 18:48:08 +0530, Puneet Goel wrote: >that there can be multiple incoming SMS/MMS for >different users at the same time. Also there can be multiple reads too all >at the same time. Frequency may be high considering there might be thousands >of users. >> >> >> Open/close of multiple databases could be time consuming. >> >> >> >> that's the point. >Anything on security point of view. Can any user send some malicious script >thru SMS which can corrupt the database. My main intention of using multiple >databases is that if some user send some malicious script he should be able >to corrupt only one DB and not others. Am i right in this assumption ? Since the content of the SMS/MMS message is not important for database purposes, you might consider storing the message as a plain file in a directory that is user specific. Then the database contains just fields like: - user identifier - current message status - date/time of receipt - date/time of retransmission - pathname for content file The operating system can write the message content into a hierarchical directory structure based on successive characters of the user's identifier (which must be unique anyway). The database is used for control purposes only; records are small and written quickly. Retrieval is also fast since it would be one or two field indexing. You might want to use Userd + MessageStatus as the key. Of course, similar functionality is possible just using the operating system's directory and file management, so why is the database important to you? Regards, Chris
Re: [sqlite] suggesiton needed for using SQL lite in a situation
Hi C and Michey, Thx for the informative comments. Let me be little more specific. I need to to make a databse system where i can store SMS/MMS coming from network for all users. Later on the SMS/MMS will be forwarded to the specific user. On 6/22/06, C.Peachment <[EMAIL PROTECTED]> wrote: An important factor might be the frequency of message record insertion and/or deletion. A rate of several per minute should be no problem for a single database but several per second might cause unacceptable lockouts for readonly uses. How many writing processes will access the database "simultaneously"? So this situation says that there can be multiple incoming SMS/MMS for different users at the same time. Also there can be multiple reads too all at the same time. Frequency may be high considering there might be thousands of users. Open/close of multiple databases could be time consuming. that's the point. Anything on security point of view. Can any user send some malicious script thru SMS which can corrupt the database. My main intention of using multiple databases is that if some user send some malicious script he should be able to corrupt only one DB and not others. Am i right in this assumption ? Looking forward to hear from you. Regards
Re: [sqlite] suggesiton needed for using SQL lite in a situation
1) I make 1 DB having data for so many users. 2) I make seperate DB for each user Second approach implies that you'd have to do your own database files (users) management when adding/removing users. It also means you have'd have several database files to keep, so the simplicity of handling just one single file is lost. One advantage what I can see is that when one databse file gets corrupted, other user's data is left intact. I'd opt for the first approach and when it seems that things are getting slower over the time, browse this mailing list for some hints, tips and tricks - that usually helps a lot. :-) In any case you can break the database into multiple files later - it needs some work and changing the schema perhaps, but it's not an overkill. Current limitation is 10 attached database files but AFAIK this can be changed easily in the sources and recompiled if needed. Peter
Re: [sqlite] suggesiton needed for using SQL lite in a situation
One things to bear in mind is will you need to query data across all users? Perhaps a report or some stats for all users? If so, this is much more problematic if you have one DB per user, since you would need to ATTACH all the separate files to enable the query to work. A single DB file, such reporting is simple. Just something to bear in mind. -- View this message in context: http://www.nabble.com/suggesiton-needed-for-using-SQL-lite-in-a-situation-t1828660.html#a4991206 Sent from the SQLite forum at Nabble.com.
Re: [sqlite] suggesiton needed for using SQL lite in a situation
On Thu, 22 Jun 2006 12:59:54 +0530, Puneet Goel wrote: >I am considering using SQL Lite for my purpose. For that i need some help in >decision making. I have an applivation which nneds to store muliple number >of messages for a user. Messages will grow over time. Also there can be >thousands of users. >Which approach would be better is i use SQL Lite (From developer ease, >Security etc point of view) >1) I make 1 DB having data for so many users. >2) I make seperate DB for each user This is a decision only you can make based on local knowledge and experience. Both approaches can work. Other developers have been working with datasets containing 10's of millions of records without difficulty. An important factor might be the frequency of message record insertion and/or deletion. A rate of several per minute should be no problem for a single database but several per second might cause unacceptable lockouts for readonly uses. How many writing processes will access the database "simultaneously"? Open/close of multiple databases could be time consuming.
[sqlite] suggesiton needed for using SQL lite in a situation
Dear All, I am considering using SQL Lite for my purpose. For that i need some help in decision making. I have an applivation which nneds to store muliple number of messages for a user. Messages will grow over time. Also there can be thousands of users. Which approach would be better is i use SQL Lite (From developer ease, Security etc point of view) 1) I make 1 DB having data for so many users. 2) I make seperate DB for each user Looking forward to hear from you ASAP. Thx and Regards Puneet
