| 1:05 am on Jul 23, 2001 (gmt 0)|
Stay away. It is not a true relational database.
Best? Oracle or MS SQL Server. Might be overkill for a simple app.
But look at MySql - take a look at this discussion:
| 1:26 am on Jul 23, 2001 (gmt 0)|
Kerrace it is a good question as there are so many combinations and possibilities. I have been using both Access and File Maker Pro for some time now with great success and no complaints. Each database has it's own good points and bad points. MySQL is becoming very popular although I have not used it myself so cannot comment. Another possibility is PostGreSQL.
However, the database is only the repository for the data. You then need a language/system to get the data into web pages. ASP (Active Server Pages) is nostly used with Access and its big brother SQLserver, whilst Lasso is mostly used with FileMaker Pro.
Interestingly, I stumbled across another system yesterday that can be used with any ODBC database via CGI called WhizBase [whizbase.com] which may be worth checking out.
I would suggest that you need to do some more research into each of the database/system combinations before making a final decision. Do some seaches on google for MS Access, Active Server Pages, FileMaker Pro, and so on and read up on it all.
Hope this helps,
(BTW Bob, are you sure that Access is not a true relational database? What is the definition of a true relational database? )
Disclaimer: I have no connection with any of the programs mentioned here....
| 3:45 pm on Jul 23, 2001 (gmt 0)|
Spoke too soon - Woz: 'conforms to Codd's 12 rules'
What I meant to say is that Access is not a client/server RDBMS.
A friend of mine came to me for some advice - he was using Access - and asked why it was so slow. He did not realize that all processing is done on the client: entire tables are sent to perform joins and queries on the client, as opposed to a client/server model, where the processing is done on the server and the only data transfer is/are the final result rows themselves.
Woz has given you some good examples, my suggestion is that you stick with a client/server model and forget Access.
| 3:51 pm on Jul 23, 2001 (gmt 0)|
I would stay away from Access personally. I have used it for largish (say 20 tables, 120k rows, 10 columns) databases and it has a nasty tendency to become corrupt unless you follow a regime of compact/repairing it.
I used to wake up at nights having nightmares about databases, i'm not joking either :)
| 5:12 pm on Jul 23, 2001 (gmt 0)|
It's also extremely important to note that if you aren't fairly experienced with the way databases work, keeping them running smoothly can be rough. Kind of like trying to run unix with no clue what you are doing. I haven't worked with access but my guess is even it can run fast if setup properly (keeping in mind that the 'client' is a script local to the server). For cheap and effective MySQL is probably as good as it get's, for protection against data loss and tons of features you probably won't need, you have to go with postgre, oracle, sqlserver or another major commercial database.
| 8:31 pm on Jul 23, 2001 (gmt 0)|
thank you all for your advice.
It looks like MS Access is not a good option.
I will check in things a bit more.
| 11:16 pm on Jul 23, 2001 (gmt 0)|
>He did not realize that all processing is done on the client
Bob, could you give some examples of this? Have you used Access yourself?
I use ASP technology where ALL the processing is done on the server and plain HTML is sent to the client.
TPK >20 tables, 120k rows, 10 columns
I agree that if your database gets to this size then you should migrate to something more robust. But for small to medium size database I see no problem. A similar question was asked re Access vs SQLserver here [webmasterworld.com].