Недавно решил разобраться с MIGxDB нашел руководства, пару видео успешно создал таблицы. Но возник вопрос по идентификаторам — судя по таблицам MODx все идентификаторы называются id, если писать отличный от id то начинаются проблемы. 1. вывод таблицы через MIGx не хотел работать, пока не прописал joxi.ru/J2b546dI4p3Vm6. 2. Если создать TV типа MIGXDB, то вывод опять не работает в логе ошибка:
[2014-12-04 16:28:52] (ERROR @ /assets/components/migx/connector.php) Error 42S22 executing statement: Array ( [0] => 42S22 [1] => 1054 [2] => Unknown column 'Recipe.resource_id' in 'where clause' )
Может называть идентификаторы id стандарт MODx? просто в документации ничего по этому поводу не нашел(
Вообще по своему опыту давно уже уяснил себе, что в MODX (в частности в xPDO) у всех объектов (таблиц) ID — всегда должен быть id. Даже если у вас на самом деле первичный ключ — это две или более колонки, все равно Primary key создавайте ID, а на те колонки создавайте Unique key. Иначе куча багов, включая невозможность удалить или обновить объект. Это касается не только MIGxDB, в нем это идет от xPDO.
К слову, мне по началу было сложно с этим свыкнуться. Еще в сотовой компании, обслуживая их биллинг на Оракле, я усвоил такую методику от Питер-Сервиса (да-да, это такие крутые ребята с доменом http://billing.ru): первичный ключ — это до 4-х согласных букв от понятного слова (если букв меньше, то и гласные годятся), например usr_id (на примере modx_users). А вторичный ключ — это дважды id, например usr_usr_id (который в таблице modx_user_attributes заменил бы колонку internalKey). Так, глядя на вторичный ключ сразу понимаешь что он именно вторичный ключ и по нему сразу понимаешь какой первичный ключ искать. Просто когда работаешь с тысячами таблиц, по-другому никак. Блин, пришлось мне как-то столкнуться с хэлп-деском HP написанном на MSSQL нифига не по такой методике, уверяю — там мозги можно было вывихнуть.
Вот мне на MODX-е не удалось такую методику применить, пришлось отвыкать от нее.
Спасибо, Николай прояснили. Меня это немного удивило, когда я Базы Данных проходил, то преподаватель говорила, что PK надо создавать понятный, чтоб потом в тонне id не путаться. Кстати про 4 согласные буквы — это корпоративные или общепринятые понятия?
PK надо создавать понятный, чтоб потом в тонне id не путаться
Told you.
Кстати про 4 согласные буквы — это корпоративные или общепринятые понятия?
Не скажу за всю Одессу, но такое видел только в их продуктах, больше нигде (хотя не могу утверждать, что они это ни у кого не подсмотрели). Но их методика мне нравится, и как раз понятности очень способствует.
И лично от меня на счет 4 букв: на мой взгляд это оптимально. В большинстве случаев четырех букв было достаточно, чтобы боле менее понимаемое название дать, и при этом оно часто уникальное получается (далее уже программными средствами следим), да еще и не раздувается в длине. Когда длина и форма ключа унифицированная, тогда сразу средь других колонок выкупаешь такие ключи. При работе с большим количеством колонок это очень помогает.
Спасибо, буду иметь ввиду. А то обычно называю имятаблицы_id.
Так часто длинные имена получаются, и как я и говорил, визуально не сразу выкупаешь. Но, это уже кому как больше нравится.