Sadus, (criterias и coefficients в таблицах expertise_1lvl и expertise_2lvl нужно заменить на criterias_id и coefficients_id)
см. п.3 в моём предыдущем комментарии.
Добавлю, что для корректной работы базы по экспертам, цепочки связей должны быть такими (указаны таблицы и типы связей: 8 - знак бесконечности):
1. [users] 1<-8 [expertise_main]
2. [criterias] 1<-8 [coefficients] 8->1 [expertise_main]
3. [expert_level] 1<-8 [coefficients]
1. В любой экспертизе есть определённые конкретные люди.
2. Коэффициент (дробный показатель) состоит из критерия (название) и привязан к конкретной экспертизе.
3. Каждый коэффициент однозначно определяется уровнем эксперта.
Sadus, 1. (меня все за это ненавидят) Забудьте про поле "pass" как про страшный сон в базе данных. Есть только поле hpass/hashpass - хешированный пароль и salt - соль для конкретного пользователя.
2. start_date, end_date, duration - зачем тут duration?! Это лишнее поле статических данных, которое впоследствии может привести к ошибкам. Нужно вычислять всегда: duration = end_date - start_date
3. id_expert_1_lvl - если начали считать левелы (т.е. появились типы экспертов), то сразу нужно делать отдельную таблицу левелов.
4. fio* и full_name - лучше разделить на 3-и отдельных поля.
5. роли всех пользователей нужно сделать в одной таблице и добавить таблицу типов: "admin", "helpdesk", "доктор", "пациент", "заведующий" и т.д. и уже оттуда по ID-шникам ролей - распределять по бизнес-процессу.
zwezew, 1. Про "вот тут" - да, так и делают: подбором, чтобы выглядело красиво и всё.
2. Про анкор-поинт: смещают центр вращения из левого верхнего угла координат объекта к его центру как половину от высоты и ширины.
SmInc, По-моему, мы говорим о разных вещах.
Речь идёт про исполняющийся бинарник (программу-клиент игры), логику работы которого нужно восстановить и понять как формируются сетевые запросы к серверу, чтобы создать тоже самое.
