Планируется ли в будущих релизах возможность давать осмысленные имена таблицам и полям для обращения к ним напрямую запросами вида
SELECT * FROM <DATA_TABLE>Customer WHERE Name LIKE '%Ромашка%'
вместо текущего
SELECT * FROM <DATA_TABLE>45 WHERE f955 LIKE '%Ромашка%'
?
2
Осмысленные названия таблиц и полей
Автор Givik, 15 марта 2011 21:45
Сообщений в теме: 3
#1
Отправлено 15 Март 2011 - 21:45
#2
Отправлено 16 Март 2011 - 10:10
Возможно, уже думали над этим.
#3
Отправлено 17 Март 2011 - 12:08
У полей типа f955 есть несколько приемуществ над Name:
1. При переименовании полей, f955 всегда одинаков. Например вы сделали конфигурацию пользователю, в отчетах используется Name, затем пользователь зашел в конфигурацию и решил переименовать Name в FIO, все отчеты перестанут в этом случае работать. К сожалению, ситуация с переименованием достаточно частая. По этой причине в сложных отчетах желательно не использовать функции типа data_table.
2. f955 уникален, вы не встретите второго поля f955. Если вы добавляете другое поле в другую таблицу, то у него будет идентификатор f956. Соответсвенно не может возникнуть путаницы с наименованиями полей в разных таблицах. В вашем случае Name может быть в нескольких таблицах, и при селекте из двух таблиц, поля придется преименовывать.
3. третье приемущество вытекает из свойства уникальности - масштабируемость. Таблицы можно разбивать на более мелкие подтаблицы, объединяя их например с помощью представлений. Фактически нескольких маленьких таблиц, абсолютно прозрачно можно привести к одной большой таблице, все наименовая полей уникальны. Также архитектуру с уникальными полями, проще адаптировать к нереляционным б.д.
Недостаток полей с номерами в нечитабельности при редактировании кода, планируется сгладить, путем автоматической подсветки например "f955" в "таблица-имя поля", в редакторе.
1. При переименовании полей, f955 всегда одинаков. Например вы сделали конфигурацию пользователю, в отчетах используется Name, затем пользователь зашел в конфигурацию и решил переименовать Name в FIO, все отчеты перестанут в этом случае работать. К сожалению, ситуация с переименованием достаточно частая. По этой причине в сложных отчетах желательно не использовать функции типа data_table.
2. f955 уникален, вы не встретите второго поля f955. Если вы добавляете другое поле в другую таблицу, то у него будет идентификатор f956. Соответсвенно не может возникнуть путаницы с наименованиями полей в разных таблицах. В вашем случае Name может быть в нескольких таблицах, и при селекте из двух таблиц, поля придется преименовывать.
3. третье приемущество вытекает из свойства уникальности - масштабируемость. Таблицы можно разбивать на более мелкие подтаблицы, объединяя их например с помощью представлений. Фактически нескольких маленьких таблиц, абсолютно прозрачно можно привести к одной большой таблице, все наименовая полей уникальны. Также архитектуру с уникальными полями, проще адаптировать к нереляционным б.д.
Недостаток полей с номерами в нечитабельности при редактировании кода, планируется сгладить, путем автоматической подсветки например "f955" в "таблица-имя поля", в редакторе.
#4
Отправлено 18 Сентябрь 2013 - 11:41
Тогда сделайте, пожалуйста, чтобы комментарии к таблице и к полям заполнялись соответствующими рускоязычными названиями, чтобы можно было легко ориентироваться по описанию таблиц.
Я забежал вперед и сам поменял комментарии к таблицам:
select CONCAT('alter table ','f_data', id, ' comment =''', name_table, ''';') from f_tables
Я забежал вперед и сам поменял комментарии к таблицам:
select CONCAT('alter table ','f_data', id, ' comment =''', name_table, ''';') from f_tables
Количество пользователей, читающих эту тему: 2
0 пользователей, 2 гостей, 0 анонимных