My first thought when you asked this: If you have to ask, just go with MySQL. If for no other reason than to ease learning. As you said before, Googling for each has way different results. I have found that learning how to do things (with PHP in my case) with Mysql was easy just because there are SO MANY people using it, and therefore way more examples out there.
Having said that, I love SQLite now that I am learning it. But it took much more effort because the docs and examples are not as abundant. For example, some abstraction layers work with SQLite3, and others only work with SQLite2. In this case, it was so much easier to work with Mysql, for me. But, now I've learned a bit more, and I am liking PDO for access to either Ver 2 or 3. (of course I am using PHP 5.1.2.) I started my app with Pear::DB, which would only work with SQLite 2, only because I tried the examples I found and none worked with other abstraction layers/drivers. Now, I figured out PDO, and I am very happy. As far as the question of "will SQLite handle it?" goes, I say no prob. I have several sites running SQLite now for small data driven tasks, and I love the idea of no db engine running, no separate process to deal with. Of course, if I was to run a large user-base on a system, (like 1000 users) I would go with Mysql or maybe MSSQL. That's just my preference. In your case, do you want to spend more time learning? And want the portability and ease of use of a file-based db? Then go with SQLite. I have found it to be quite reliable. If you want to get up and running quicker by spending less time finding examples and documentation, then go with Mysql. Mysql is very portable and easy to run, and EVERYONE has it. Ah, it's worth noting too, I kind of like the data typing and how you must conform to it in Mysql. On small web apps, like you describe, SQLite will handle it fine, but keep in mind that if you want to have restrictive data types, then Mysql will be better. IMHO. Maybe some of you SQLite experts can elaborate, but as far as I know, with SQLite, if you say you want a varchar(50) column, and you insert 55 chars, it will take it. Whereas in Mysql, it wont. My $.02. Hope it helps. On 4/6/06, Lenster <[EMAIL PROTECTED]> wrote: > > I am investigating which would be the most appropriate RDMS to use for > a new Intranet based application. I have rounded down my choice to two > candidates - SQLite and MySQL. > > > The application needs to be available to about twenty users on a daily > basis, with most of those users making no more than five 'write' > transactions a day, and around twenty 'read' transactions a day. > > > Depending upon its success the application may well develop to > incorporate other datasets and users - so the RDMS needs to be able to > develop without difficulty. > > > IMHO SQLite looks as though it would be the fastest to develop and with > the least resources required but after reading some SQLite > documentation: > > > "A good rule of thumb is that you should avoid using SQLite in > situations where the same database will be accessed simultaneously from > many computers over a network filesystem." > > > I am concerned that even though I expect light usage it is likely that > multiple users will access the same database concurrently. > > > Would I be correct in assuming that MySQL is a safer (longterm) bet? > > > Thanks for any and all responses > > > Len > -- > View this message in context: > http://www.nabble.com/Most-appropriate-Web-based-database-%28Newbie%29-t1404628.html#a3780531 > Sent from the SQLite forum at Nabble.com. > > -- Greg Fischer 1st Byte Solutions http://www.1stbyte.com
