[docbook-apps] Re: XML databases

[Norman Walsh]

Camille Bégnis  writes:
> thanks for this interesting discussion, what DB would you use or suggest
> for XML?

I’m strongly biased to suggest a particular commercial database, one
that you can download and use for free from developer.marklogic.com.

But I hear good things about BaseX as well and eXist has been around
for ages.

Be seeing you,
  norm

-- 
Norman Walsh  | There has never been a perfect
http://nwalsh.com/| government, because men have passions;
  | and if they did not have passions,
  | there would be no need for
  | government.--Voltaire


signature.asc
Description: PGP signature

Re: [docbook-apps] Re: XML databases

[Camille Bégnis]

Hi all,

thanks for this interesting discussion, what DB would you use or suggest
for XML?

Camille.


Le 06/04/2018 à 11:43, Norman Walsh a écrit :
> 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
>


-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

[docbook-apps] Re: XML databases

[Norman Walsh]

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


signature.asc
Description: PGP signature