One CRM in few DB

[partomas]

Hello, I have "strange question" is it possible to run ESOPO CRM in few DB, I mean CRM in one DB, but mail in another DB. Now we have a big scoupe of e-mails and any query in mail are freezing all the system. So my idea is to transfer mail storage to separate DB. Has anyone such experience, ideas how to do so or can help us for additional fee.

[Enju]

How big is your emai table? Mine already has 16GB at this moment and I am afraid that the same case will happen soon.

[partomas]

Mine already 21.4 GB at the moment and it's growing.

[yuri]

As an option, delete all emails with an empty parent field.

[partomas]

Yes, it can solve a bit of issue, but in general it will stay a lot GB in mail table which affect a whole system performance when someone is doing any activities there. The split of DB for Mail could minimise it.
P.S. we have 21GB for mail only, now.

[esforim]

Kinda ruin the purpose of CRM/Espo. But I guess this is a 'solution' until it is possible or a new idea can be implement.

[partomas]

There are no so many emails with no parent field, most of them it's related to some account/contact or support issue. Cleanup of unrelated emails didn't change volume of email DB dramatically, even if we cleanup all emails older than 5 years by default.

[shalmaxb]

could it not be possible to treat the emails similar to the images in the upload folder? Save the content to a webfolder and reference in database.

[A. Conrads]

Hi,
Recently I had to delete emails all manually because the cleanup job timed out.
I deleted about 35000 mails. At least the job is working again. Outsourcing the mails, e.g. to the upload folder, would certainly not be a bad solution. Web space is usually not the problem, but rather the size of the database.

[WisTex]

Hello, I have "strange question" is it possible to run ESOPO CRM in few DB, I mean CRM in one DB, but mail in another DB.

That is something that would technically be possible but would require a rewrite of the software and come with some limitations and require some creativity.

For example, the software would only be able to do JOINS if the two databases are located on the same server and use the same connection (i.e. with the same database user credentials). This is a little-known feature of MySQL.

But, if the databases do not use the same connection, you can't use JOINS anymore when querying tables in different databases. While you could still get the data by using separate queries to each database, it makes it harder to sort results, since you can't use a JOIN. Maybe with some creativity, it can be done, but such a design forces you to rethink how you interact with the data.

Another possible solution would be to only store the meta information in the CRM database, and that points to the body of the email stored elsewhere, perhaps in another database or a file. The downside to this is you wind up using more disk space since you are storing the meta information twice, and it makes it difficult to search the body of the emails and cross reference that with other data in the CRM at the same time, again, because for the JOIN issue.

I'm not speaking for the developer, but I will note that it is technically possible but would probably require significant rewriting of the code.