Как увеличить максимальную длину имени идентификатора?

Имена таблиц, имена столбцов, имена индексов и т. д. В MySQL (и MariaDB) они имеют максимальную длину 64 символа. Как я могу увеличить это?

Дублируйте здесь: Максимальная длина имени столбца в MySQL

Документация по MySQL здесь: https://dev.mysql.com/doc/refman/5.7/en/identifiers.html

Документы MariaDB здесь: https://mariadb.com/kb/en/mariadb/identifier-names/

Проблемный ответ: переключитесь на PostgreSQL и перекомпилируйте .

Справочная информация: имена столбцов с префиксом имен таблиц в сочетании с именами таблиц с префиксом имен подпроектов. Обычно названия проектов короткие, но два только что столкнулись, и по крайней мере одно из них станет немного длиннее.

Пример:

/* One MySQL Instance for in-house applications called "MySQL" on port 3306.  
 * One MySQL schema (database / catalog) per application "intranet_website".
 * Several sub-project prefixes per application, example: "finance_"
 * Individual table-name: "invoice"
 * Specific column-name: "TotalAmount"  ****/
CREATE TABLE intranet_website.finance_invoice_tbl (
    -- ...
    finance_invoice_TotalAmount DECIMAL(20,2),  -- 27 chars
    -- ...
)

Это может показаться чрезмерным, но примите во внимание соглашения об именах Java или даже просто .Сеть.

com.companyname.intranetwebsite.finance.invoice.getTotalAmount() // 63 chars
IntranetWebsite.Finance.Invoice.GetTotalAmount() // 47 chars

Примечание. Я не считаю нужным ставить перед столбцами имена таблиц. Однако есть несколько случаев, когда это становится незначительно полезным для соединений без повторных соединений одной и той же таблицы. Я знаю по крайней мере один конкретный случай, когда написание кода SQL-кода было намного проще реализовать благодаря этим префиксам.


mysql mariadb limits
person ebyrob    schedule 24.05.2017    source источник
comment
Это жесткий предел, его нельзя увеличить. Если бы это было возможно, документация, на которую вы ссылались в вопросе, указывала бы значения конфигурации для этого.   -  person Adrian    schedule 24.05.2017
comment
Это не ответ на ваш вопрос, но разве вы не можете создать отдельную базу данных для каждого проекта и назвать ее соответствующим образом? Это уберет по крайней мере названия проектов из уравнения   -  person Kitet    schedule 24.05.2017
comment
Вы можете сделать это, только загрузив исходный код mysql, изменив необходимые части кода, скомпилировав и создав. (Если вы можете :))   -  person abeyaz    schedule 24.05.2017
comment
Возможно, проблема в нормализации?   -  person Dhruv Saxena    schedule 24.05.2017
comment
Просто чтобы быть уверенным, вы имеете в виду проекты разработки или проекты, представленные в вашей базе данных? Потому что, если вы имеете в виду проекты, представленные в базе данных, вам, вероятно, не нужны отдельные таблицы для разных проектов. Кроме того, почему вы добавляете префикс ко всем столбцам с именами таблиц, когда просто полностью определяете имена столбцов (table_name.column_name) уже нет?   -  person Uueerdo    schedule 24.05.2017
comment
@Uueerdo это данные бизнес-логики, поэтому, например, Finance_ — это один проект. склад_ другой. Так что я бы сказал, что это подкомпоненты системы. Еще до того, как я начал работать над этой системой, было принято ставить перед столбцами имя таблицы для ясности и удобочитаемости.   -  person ebyrob    schedule 25.05.2017
comment
@DhruvSaxena Я думаю, что мы попадаем где-то между 2NF и 3NF. Кажется, это дает нам достаточный контроль и производительность, не заходя слишком далеко в звездные схемы для того, что мы делаем. Я не понимаю, как большее количество таблиц сделает имена короче.   -  person ebyrob    schedule 25.05.2017
comment
@abeyaz Я не предпочитаю нестандартную компиляцию, но и не полностью против этого. Однако меня больше всего беспокоит необходимость тщательно протестировать подобное изменение. Документы PostgreSQL говорят о том, что он уже довольно хорошо протестирован на этой платформе.   -  person ebyrob    schedule 25.05.2017

Ответы (1)


arrow_upward
4
arrow_downward

Вероятно, это невозможно сделать, как уже предлагали другие в комментариях.

Однако вам не это нужно делать.

Имена столбцов с префиксом имен таблиц совершенно не нужны, поскольку SQL предлагает синтаксис tablename.columname, который можно использовать для различения столбцов. На самом деле, большинство программистов, которых я знаю, полностью согласятся с тем, что добавление перед каждым именем столбца имени таблицы, которой он принадлежит, было бы очень раздражающим.

Имена таблиц с префиксом имени проекта также не нужны, потому что для этого и нужны каталоги/схемы. Кроме того, большинство СУБД поддерживают синтаксис catalogname.tablename. Если у вас есть несколько проектов с общими таблицами, и ваша СУБД не поддерживает связи между каталогами, то я бы предположил, что у вас возникла проблема рефакторинга проекта или проблема выбора СУБД, а не проблема с именованием таблиц.

Кроме того, если вы считаете, что 64-символьные идентификаторы короткие, попробуйте Oracle. О, как весело вам будет!

person Mike Nakis    schedule 24.05.2017
comment
Префиксы столбцов — это битва, в которой я участвовал в этом проекте. Я растерян. Это одно приложение с почти 300 таблицами и около десятка подпроектов. На самом деле я настаивал на префиксах подпроектов, особенно с учетом возможности совместного использования одного экземпляра базы данных с другими приложениями в компании. Я хотел, чтобы схемы/каталоги использовались на очень высоком уровне. По одному на приложение, с несколькими общими схемами, возможно, по одному на отдел. Хотя, я полагаю, сами каталоги могли бы использовать префиксы... Мне все еще не нравится идея почти 100 каталогов. - person ebyrob; 25.05.2017
comment
@ebyrob - Время разогреть свое резюме? - person Rick James; 26.05.2017
comment
@RickJames Если бы я прыгал с корабля каждый раз, когда кто-то диктовал второстепенное руководство по стилю (раздражающие префиксы), я бы никогда ничего не сделал. В более общем смысле, это, вероятно, мое образование, которое требует некоторого внимания. Или если я просто делаю это неправильно, ПОМОГИТЕ! - person ebyrob; 26.05.2017
comment
Это кажется хуже, чем незначительная проблема со стилем - кажется, что шоу-стоп, если он не помещается в доступное пространство. (Я бы не стал пытаться перекомпилировать, чтобы увеличить 64. Подумайте, что будет, если при обновлении!) - person Rick James; 26.05.2017
comment
@RickJames Мы решили по возможности выбирать более короткие названия проектов, пока этого было достаточно. Просто для ясности: вы, несомненно, считаете, что 64 символа достаточно для любого отдельного субидентификатора, например, .companyname. из пути к классам java, и ни один язык (не только SQL) не должен поддерживать более длинные идентификаторы? Или SQL как-то особенный в необходимости ограничения в 64 символа? Это 80 столбцов нашего века? - person ebyrob; 21.06.2017
comment
Как говорит @Mike Nakis, схемы и каталоги уже решают эту проблему, и нет необходимости использовать более 64 символов. Что вам нужно сделать, так это снова поднять вопрос. Я согласен и чувствую, что миграция баз данных сложна, но когда они с самого начала созданы для того, чтобы взорваться кому-то в лицо, это почти единственное, что вы можете сделать, чтобы предотвратить возможный апокалипсис. В период миграции я бы предложил заменить исходные таблицы движком федеративных таблиц и указать их на настоящие. Таким образом, у вас не будет простоев в производстве, и вы по-прежнему сохраните возможность чтения/записи данных. - person Dragas; 31.08.2018