I got a few questions about databases:

1 Is MySQL the *best* to use for a large collection of records? (ie. fastest, most secure, ease of use) (about 13000+ records BTW) (any alternatives? esp free ones)

2 I know this depends on a lot of factors, but, How quickly should you get a return result from a search?

3 When adding more records to the DB is it easy to get them alphabetic & grouped. (ie. only a handful of records at a time)

4 When working together with a shopping cart, are there any compromises to be aware of?

Kaiser

-(>_<)DO~/)-*

"Welcome to the party pal"

1 Is MySQL the *best* to use for a large collection of records? (ie. fastest, most secure, ease of use) (about 13000+ records BTW) (any alternatives? esp free ones)

The *best* would be Microsofts SQL Server, but it is also VERY, VERY expensive. MySQL, depending upon the hardware it is running on, should suffice in your situation - 13,000 records is not that many. The speed is determined mainly by the hardware and how well the queries are written. I've seen situations on MS SQL where two queries would return the same data. One would take so long that it would occasionaly time out, the other worked in just a few seconds. Ease of use is about the same.

2 I know this depends on a lot of factors, but, How quickly should you get a return result from a search?

Depends upon how the data is structured and how the queries are written. One second to several seconds.

3 When adding more records to the DB is it easy to get them alphabetic & grouped. (ie. only a handful of records at a time)

You don't add records in any particular order. You can retrieve them in any order or quantity you need.

4 When working together with a shopping cart, are there any compromises to be aware of?

I don't have enough experience in this area to comment. But, the coding (ASP/PHP/Etc) is usually the issue when dealing in this area more so than the database.

Michael J

Thanks Michael J that's nice & concice, now I think about it my system has about 90,000+ files on this partition alone... duhh
I think the guy who has this site doesn't know how to use his database - it is hard to find what you want at the best of times & the listing is far from aplhabetic.

If anyone else knows a bit about the shopping cart, it would nice to know about download speed vs cryption etc.

-(>_<)DO~/)-*

"Welcome to the party pal"

I just want to echo Michael's comment that 13,000 records is not that many...The biggest table we use at work has 100,000,000 rows. Start querying that badboy with a join with 4 other tables, ranging in size from 2,000,000 to 42,000,000, and you're talking about some serious performance issues. mySQL will handle 13k just fine. I doubt it would take more than a second or two to retrieve all 13k and sort them. Obviously complex queries can take a long time even on 'small' datasets.

SQL Server is getting more and more affordable...You can get it with small business server for $1k - $2k.

I have no idea what you're talking about on shopping cart considerations...Download speed and encryption? Compromises? Essentially all the *real* shopping cart solutions I'm aware of use databases of some kind, and speed and encryption are only compromised if you do it wrong.

Good luck,
-SN

I figure if data is encrypted, it has more bits, therefore to transfer those bits from one computer to another would take 0-l-o-n-g-e-r-1, it might only be nano seconds, but surely it would.

I don't think it can be classed as a *real* shopping cart, as it seems to be a big bag of fubar. The guy runs his shop from a unit, because he doesn't make enough money to justify a shop front so 1k or 2k is probably a teeensie bit tooo much.

enlighten me further

-{>_<}DO~/}-

"Welcome to the party pal"