Added SQL indexes

[bohdan-vorona]

Checked all the tables and added SQL indexes where needed.

[samdark]

Were the indexes added by looking at EXPLAIN of actual queries?

[bohdan-vorona]

Were the indexes added by looking at EXPLAIN of actual queries?

I executed EXPLAIN for some tables but in most cases decisions were made by obvious non-optimized tables with relation, like a table with a field customer_id.

[samdark]

@w911 need your input.

[cgsmith]

See here: https://twitter.com/cgsmith105/status/1625128020620070912?t=fSglZt1--nWaavjYEZoUqw&s=19

[bohdan-vorona]

Thanks, Chris

Is it a PK? 👉 The PK is enough!

I suppose here he meant the primary keys of the tables themselves. So, it's "the easiest one", so we can skip it)

Is it a target of a foreign key? 👉 Definetely!

Only several tables have real foreign keys. So, the fields like {alias_id/customer_id/facility_id/service_id} are "foreign keys" in our cases because they are related to other tables' field ID.

Are you using it to find rows? 👉 Definetely!

All those "foreign keys" are needed for: joining other tables, using related tables in GridViews (it means order by the fields, sort by the fields).

I also added indexes for some fields that are "important" for selecting/filtering by like {status/superuser/abbreviation}. Potentially they may be excessive for indexing and we can remove indexes for such columns.

@samdark Your thoughts about all this?

[samdark]

Only several tables have real foreign keys.

That's not good. Also, it's better to add FK and indexes explicitly since only MySQL adds these automatically. PostgreSQL, for example, does not.

[samdark]

I also added indexes for some fields that are "important"

1. The importance should be measured.
2. The problem with too many indexes (slow inserts, buffer size bloat etc.) could be solved by carefully using composite indexes.
3. Before/after EXPLAIN should be compared.

[cebe]

Only several tables have real foreign keys. So, the fields like {alias_id/customer_id/facility_id/service_id} are "foreign keys" in our cases because they are related to other tables' field ID.

For these, instead of adding a generic index, a foreign key should be added explicitly.

[bohdan-vorona]

@samdark @cebe

For these, instead of adding a generic index, a foreign key should be added explicitly.

So, are we going to replace the added generic indexes like {alias_id/customer_id/facility_id/service_id} with real foreign keys with cascade deletion? If yes, I can do this.

[cgsmith]

@bohdan-vorona yes I think that is good for adding foreign keys. This is a low priority.

[cebe]

Whether to allow cascade deletion should be decided for every foreign key. I would not allow it for all in general.

[bohdan-vorona]

@bohdan-vorona yes I think that is good for adding foreign keys. This is a low priority.

Ok.

[samdark]

For these, instead of adding a generic index, a foreign key should be added explicitly.

Not instead. In addition to. Only MySQL adds indexes automatically. Other DBMSes do not.