Multiple DB / concept question

[eluser]Jonas G[/eluser]
Hi.

I'm building a site that gets alot of xml data pushed to it. All xml data is saved in a database. This data has to be shared with 3-5 other sites (all on the same host though) and I'm trying to figure out the best way of doing this. As I see it, I have a couple of options:

1. Saving the data to a single database which all the sites connect to. Pros: I only have to save the data one place. Cons: I have to connect to more than one db from every site + I have to figure out how to use IgnitedRecord (as I need the mapping) over more than one db (if that is even possible).

2. Save the data to all the databases. Pros: I don't have to worry about connecting to multiple databases (except for the xml parser). Cons: The data is very sensitive and if I miss a single entry it would be bad. If I have 4 different databases that means 4 places where things can go bad

I feel option 2. is the better option but would love to hear some opinions.

Jonas

[eluser]rogierb[/eluser]
Have you thought of using database replication? Use one Db as a master and the others as slave. This way you can add databases if you need to.

[eluser]Dam1an[/eluser]
I think the best way to do this would be to have an intermediate handler, so you can start off with the easy approach for now (just dealing with the one database) and if/when you need to switch to the multi database approach, you can just change the code in the intermediate handler, and it should all carry on working

[eluser]m4rw3r[/eluser]
I have a database abstraction in the works which will be able to reroute writes to another connection (for master/slave layout).
(It is also very fast and flexible.)

It will be compatible with IgnitedRecord (I think, dunno how similar to CI's it is yet), as IgnitedRecord uses its own SQL-builder.

It is almost ready for an mid-development release, containing a sql-builder (NOT IgnitedQuery, instead it is a faster, smaller and more flexible variant) and the database abstraction itself. A manual is also included (not falling into the same trap as I did with IgnitedRecord, writing the manual as I go now ).
It will lack ORM, which I will do a complete rewrite (and architectural redesign) of IgnitedRecord and then bundle it with that abstraction (probably very small similarities with IR).

[eluser]Jonas G[/eluser]
Thanks for all the replies

@rogierb: I will try and read up on that - It's not anything i've heard about before.

@Dam1an: It is certain that there will be multiple databases so I think it's better to get it right the first time.

@m4rw3r: That sounds truly awesome - I would love some more information on that.
And you're right about IR - it could sure use an updated manual. I feel there's a lot of things I could be doing better/faster/more efficient