[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: XML databases
Dave Pawson <dave.pawson@gmail.com> writes: > Agree with your logic. Good for thousands (hard to index) > Less so for hundreds (I use db indexing) Yes, but as I said, it depends on the app you’re trying to build. drinks.nwalsh.com: ~200 small documents, easy to build in a DB, harder outside. so.nwalsh.com: ~600 documents and growing, easy to build in a DB, *much* harder outside photos.nwalsh.com: ~14,000 documents, same story tzinfo.nwalsh.com: ~225,000 documents, probably not practical any other way (Drinks.nwalsh.com is a simple app, you could do that off the filesystem with a little bit of Python and some cleverness. So.nwalsh.com would be much harder because it’s using full-text, semantic, and geospatial indexes and runs queries in real time that rely on those indexes to perform well.) > I'd hate to have the data in a corrupt database.... Or a corrupt filesystem. I don’t think databases are inherently a riskier place to put your data. And if having them in a database encourages you to have a more reliably backup strategy, they’re arguably less risky. Backup early. Backup often. And remember: if you copy data to a backup drive, then remove the data from your computer, you don’t have a backup, you have a vulnerable data set on a single external drive. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Limited in his nature, infinite in his http://nwalsh.com/ | desires, man is a fallen god who | remembers heaven.--Lamartine
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]