Partition Database into Two

Describe the issue or problem
I manage quite a large journal with articles ranging back to 2008 (maybe even earlier). Clearly, the database is getting bigger and so is the previous issues page. I am thinking of partitioning the journal website into two where, on one site, I have articles prior to say 2021.

I am an IT prof and teach databases as one of the core subjects. I, therefore, am intimately familiar with ERDs, tables, foreign keys, constraints, etc. I am currently on OJS ver. 3.3.0-19. I will research which tables need to be split and where.

Let me have your thoughts on this, please.

Hi,

I don’t think this is necessary and just complicates things. We have a journal with over 9400 articles. It runs fluidly on one database, which is about 600 MB in size. So not large.
The database mostly stores metadata. Galleys are stored on disk, anyway. If you want to do full-text indexing, I recommend to have a look at the Lucene plugin and Solr/Lucene installation, which is way more potent than full text indexing in the relational database.

1 Like

Apart from the issue of full-text indexing, in our experience hosting hundreds of journals, the table that ends up growing the most in the vast majority of installations is metrics.

1 Like