Dave Pawson <> 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 <> | Limited in his nature, infinite in his
http://nwalsh.com/ | desires, man is a fallen god who
| remembers heaven.--Lamartine
