В целом структура плохо нормализована, типы данных выбраны неоптимально, пропущены ограничения по внешним ключам (целостность данных).
Индексы вообще нигде не используются (кроме стандартного PRIMARY, который создается вместе с таблицей).
Нестандартный default_collation=utf8mb4_0900_ai_ci (зачем?)
table added_education:
id_doctor - отсутствует FK связь (Constraint)
startyear - INT - неоптимальный тип данных (должен быть TINYINT)
stopyear - INT - неоптимальный тип данных (TINYINT)
active - INT - неоптимальный тип данных (TINYINT)
needaccept - неоптимальный тип данных (TINYINT)
table table admin:
id_user - INT (11) -отсутствует FK связь (Constraint)
table area:
id_region - отсутствует FK связь с таблицей regions (Constraint)
table articles:
id_doctor - отсутствует FK связь с таблицей doctors (Constraint)
datecreated - INT - правильно было бы DATETIME / TIMESTAMP
draft - INT - неоптимальный тип данных (TINYINT)
del - неоптимальный тип данных (TINYINT)
activated - неоптимальный тип данных (TINYINT)
table calendar:
id_doctor - отсутствует FK связь с таблицей doctors (Constraint)
id_procedure - отсутствует FK связь с таблицей procedure (Constraint)
starttime - Для начала дня лучше было бы использовать CHAR (4 байта), вместо плохо читаемого INT в секундах (4 байта)
stoptime - аналогично
date - INT - должен быть TIMESTAMP / DATETIME
vacation - неоптимальный тип данных (TINYINT)
table captcha_counter:
В целом не было смысла писать эти данные в БД. Достаточно было бы записи в кеш.
ip_client - VARCHAR(45) - должно быть для ipv4 INT(4), для ipv6 BINARY(16)
registration_cnt - INT(5) - неоптимальный тип данных (TINYINT)
forgot_cnt - INT(5) - неоптимальный тип данных (TINYINT)
table catalog:
В текущем виде вложенность категорий ограничена, нужно было строить граф (сейчас для каждого нового уровня вложенности придется создавать новую таблицу, если это характеристика станет динамической - придется все переделывать)
id_category - отсутствует FK связь с таблицей category (Constraint)
id_subcategory - отсутствует FK связь с таблицей category (Constraint)
id_doctor - отсутствует FK связь с таблицей doctors (Constraint)
id_doctor_update - неоптимальный тип данных (TIMESTAMP|DATETIME)
draft - неоптимальный тип данных (TINYINT)
del - неоптимальный тип данных (TINYINT)
favorite - неоптимальный тип данных (TINYINT)
datecreated - INT - правильно было бы DATETIME / TIMESTAMP
dateupdated - INT - правильно было бы DATETIME / TIMESTAMP
activated - INT - неоптимальный тип данных (TINYINT)
needupdate - INT - неоптимальный тип данных (TINYINT)
change_dateupdate - INT - правильно было бы DATETIME / TIMESTAMP
change_id_doctor_update - отсутствует FK связь с таблицей doctors (Constraint)
change_id_category - отсутствует FK связь с таблицей category (Constraint)
change_id_subcategory - отсутствует FK связь с таблицей subcategory (Constraint)
table catalog_info:
id_region - отсутствует FK связь с таблицей regions (Constraint)
del - INT - неоптимальный тип данных (TINYINT)
table catalog_info:
type - ENUM('PATIENT', 'DISEASE', 'DRUGS') - нужно было выносить типы в отдельную категорию, а тут привязывать по FK
del - INT - неоптимальный тип данных (TINYINT)
table clinic:
id_user - отсутствует FK связь с таблицей users (Constraint)
id_organization - отсутствует FK связь с таблицей organizations (Constraint)
id_country - отсутствует FK связь с таблицей countries (Constraint)
id_region - отсутствует FK связь с таблицей regions (Constraint)
id_area - отсутствует FK связь с таблицей areas (Constraint)
id_station - отсутствует FK связь с таблицей stations (Constraint)
post_code - INT (6) - должно быть MEDIUM INT (6) ZEROFILL
part_house - VARCHAR(5) - должно быть CHAR(5)
datereg - должно быть DATETIME / TIMESTAMP
activated - неоптимальный тип данных (TINYINT)
del- неоптимальный тип данных (TINYINT)
stoprecord - INT(2) - неоптимальный тип данных (TINYINT)
excludesearch - INT (1) - неоптимальный тип данных (TINYINT)
table clinicinfo_change:
id_clinic - отсутствует FK связь с таблицей clinics (Constraint)
house - VARCHAR - должно быть CHAR
part_house - VARCHAR - должно быть CHAR
needaccept - неоптимальный тип данных (TINYINT)
table coming_soon:
email - VARCHAR(60) - нужно VARCHAR(320). https://tools.ietf.org/html/rfc5321.html
table comments:
table doc_contracts:
is_sign - INT(1) - неоптимальный тип данных (TINYINT)
table doc_report2grid:
id_doc_report - отсутствует FK связь с таблицей doc_reports (Constraint)
id_grid - отсутствует FK связь с таблицей grid (Constraint)
table doc_reports:
table doctor:
subspecialty - вероятно нужно было для этого завести отдельную структуру и организовать связь (ONE-TO-MANY|MANY-TO-MANY). В текущем исполнении по этому полю даже поиск нормально сделать невозможно
startprofdate - INT(1) - должно быть DATETIME / TIMESTAMP
table users:
Плохо спроектирована ролевая модель + ненормализована. В текущем исполнении пользователь не сможет иметь несколько ролей (если вдруг будет необходимо доработать систему таким образом)