[Vtigercrm-developers] Let's address the elephant in the room

[Martin Allen]

1) The fact that vTiger stores all the previous values that are changed in
a field, is actually a pretty big selling point for a lot of our clients as
it provides a full audit trail for them. What does mystify me a little bit
is why creating an Email (which is static and doesn't change) gets recorded
in mod_tracker_detail (and when your importing LOTs of Emails - which we
do) then this table gets exceptionally large!) So keeping the data is key,
but checking exactly what is being stored and possible making the structure
better (not sure how though)
2) Absolutely!
3) There is a limit to how many columns you can have in a single table, so
having two tables does increase the number of fields you can have per
module. But being able to specify a field name (ensuring that it is not a
duplicate - as that can cause no end of problems!) would be nice.
4)renaming some of the tables makes perfect sense, and ensuring a
consistent naming convention (should module names be singular or plural ?)
Splitting out the contents of vtiger_activities might help as Emails
currently go in there too!
6)Using a more modern DB library would be great!! Or even just the latest
version of PearDB would be a start!

Martin Allen


*01392 248692 - Main Office01392 690659 - Direct Line*

*[image: signature2]*

Have you visited our website recently? https://www.clystnet.com
<http://www.clystnet.com/>


The information in this email is confidential If you are not the intended
recipient, you must not read or use that information. This email and any
attachments are believed to be virus free however no responsibility is
accepted by Clystnet for any loss or damage arising in any way from receipt
or use thereof. Clystnet Ltd (company reg number 7164503) is based at
Silverdown Park, Fair Oak Close, Clyst Honiton, EX5 2UX


On Sun, 15 Nov 2020 at 22:51, Sukhdev Mohan <s.mohan at myti.it> wrote:

> Hi All,
>
> I thinks we all need to start addressing the elephant in the room. There
> are multiple things that can be improved and the most important one is the
> DB structure.
> I see these problems/bottlenecks, please follow up with your
> impressions/thoughts and if you find other please add.
>
> 1. vtiger_modtracker_basic and vtiger_modtracker_detail: these table
> increase in size exponentially as the data grows, this slows down the db
> very much.
> 2. All the _seq tables: why can’t we just use auto_increment? It would be
> safer and there would be al most 50% less tables.
> 3. All the cf tables: why can’t we create the custom field in the main
> table with the name the dev choses instead of a cf_#### where #### is an
> arbitrary number with no meaning at all post creating.
> 4. Names for the standard tables: for instance if the module/entity in the
> crm is To Do you can’t store it in vtiger_activities. I propose to
> standardise naming scheme.
> 5. Implement True Object Relationship Mapping: frankly it would be a much
> more good thing If we could interrogate for entity and get the connected
> entities without doing n queries and cycle/traverse through and will lead
> to cleaner queries.
> 5.a Use of ORM such as Eloquent or Doctrine2 could be very good IMHO
> 6. Ditch AdoDB in favour of some more modern Library, even php’s native
> PDO is better, it might even have a low footprint.
> 7. Refactoring of the db structure in general will be a good step to
> improve the situation.
>
>
> Best Regards,
> *Sukhdev Mohan* | *Software Developer*
>
>
>
>
>
>
>
> _______________________________________________
> http://www.vtiger.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20201116/5bb42200/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 10550 bytes
Desc: not available
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20201116/5bb42200/attachment-0001.png>