I found out that there are these 2 options:
- Keep all the news in a single database of one website and the other websites will fetch the news from the main one
- + Consistency/Unification – if I wanted, for example, to post news using WLWriter and an implemented MetaBlog API (or another one) or using MS Office, I could
- + When making modifications, changes to the table only need to be made once. But then again, who creates tables and then keeps changing them, right?
- + I already have something written, and I would not have to change anything
- + Easier querying if I wanted to display the news of all websites
- – If one website goes down, the news will not load on any of the “satellites“
- – If the hosting runs out of space, it will most likely again have a negative impact on all websites
- Have separate tables in the database on each website and the websites would always query the respective website
- + Speed when loading their own news
- + Load distribution across all websites, relieving a single one
- + If a website crashes, or the hosting removes or suspends it, the main web app can send me an email or otherwise notify me about the situation, and I can display a message on the website saying that the issue is being worked on.
- + Unification is possible too in the case of a good integration of web services
- – I would have to do everything as many times as I have websites, because the tables may differ (after all, everything keeps evolving). This would lead to fragmentation and increased complexity. On the other hand, it would be enough to put this into some class in
swf. - – I already have something written and I would have to modify it. But whatever, that is life, life is change.
Conclusion: Although I was initially in favor of option 1), after thinking it over here on the blog I can see that the advantages of option 2) outweigh its disadvantages, so I will try to use it.