Вопрос 341(20.04.2000) Некоторые говорят, что использование названий таблиц и название полей русскими буквами сильно тормозит работе аксеса, и возможны большие ошибки, а некоторые же утверждают, что разницы нету - хоть на арабском пиши. Каков же правильный вывод. Даже если не использовать пробелов и букв ч и я. Также некоторые утверждают, что название индексов должны отличаться от имен полей, и тем более должны быть английскими буквами без пробелов, а некоторые говорят, что разницы нету. Каков же правильный вывод. И еще: Говорят что название функций и процедур также должны быть английскими, что якобы они работают гладко (конечно, если они сами сделаны гладко), чем на русском языке. Хотя NSA пишет их на русском (а может он просто делает это для удобства восприятия для тех, кто будет пользоваться ими) Вообще хотелось бы выслушать какая должна быть профессиональная база данных - если взять условие, что с английским туго! |
Ответ. Конечно, если у Вас таблицы и поля будут состоять из 1 буквы скорость такой базы будет выше, т.к. требуется меньше памяти для загрузки программы. Например, запрос "SELECT f FROM t" работает быстрее, чем "SELECT [Фамилия директора предприятия] FROM [Таблица реквизитов организации]". Но с другой стороны, в первом запросе не хватает информации, а в другом ее явный перебор. Так что надо писать кратко, но информативно. Использование пробелов, русского текста в названии таблиц и полей не принципиально. Функции в VBA все же лучше давать на английском, т.к. хлопот будет меньше (при работе с разными версиями баз данных, а также при работе с большими базами). При этом надо учесть, что больше всего VB программ написано на английском языке и следовательно разработчики компилятора лучше всего адаптировали его к этому языку, локальные версии всегда имеют проблемы. Вывод. Поля, таблицы используйте на русском, а функции пишите на английском. Названия элементов выбирайте короткие, но понятные. Ответ 2. Андрей Беляков. Насколько я разобрался с Access 2, там запросы хранятся в предкомпилированной форме, по крайней мере - после первого использования - точно. Т.е. в обоих случаях имена полей заменены некоторым ID. Эти ID целочисленные одинаковые по размеру. Почему один из них должен обрабатываться медленнее? Адаптация компилятора под язык? В смысле - под набор букв языка? Никогда не видел такой адаптации. Компилятор, точнее его лексический анализатор, принимает определенный набор последовательностей символов(букв). Количество размер принимаемого множества символов влияет только на размер лексического анализатора, но никак не сказывается на быстродействии. Вот пример (извините за Си - на Бейсике это обычно не пишут): ... Decision decision[][]; unsigned char * pText, ch, CurrentState; ... // получение очередной буквы ch = *pText++; // и перевод анализатора в следующее состояние CurrentState = decision[CurrentState][ch]; ... Ответ 3. Виктор Конюков. 1. Создайте одинаковые по принципу базы данных с длинными запросами и короткими. Размеры их будут отличаться (даже для mde), а следовательно загружаться и выполняться будут по разному. 2. Попытайтесь вызывать из SQL функцию (конвертор цены в текст) на русском языке - будут ошибки, но не сразу (надо редактировать формы, еще что-то делать ...). Это проверено неоднократно. Требуется перегрузка всей базы данных или замена ключевых слов на английский текст, тогда ошибка исчезает. Категорически не советую в больших базах использовать функции на русском языке. В локальных версиях всегда ошибок больше из-за проблем, связанных с кодировками символов. 3. Давно известно, что корректно обрабатываются компилятором, а именно, ключевые слова (не данные) состоящие из символов от 32-127 символов, посмотрите на htm - страницы (там нет поддержки расширенного набора символов (128-255) ), т.к. другие могут восприниматься как управляющие символы. Ответ 4 (дискуссия с Андреем Беляковым) > 1. Создайте одинаковые по принципу базы данных с длинными запросами и короткими. Размеры их будут отличаться (даже для mde), а следовательно загружаться и выполняться будут по разному. Разумеется, размер текста запроса, будет разный. И запрос с длинными названиями полей будет занимать больше места. Но(!) только до предкомпиляции. Предкомпилированные версии будут совпадать с точностью до ID полей. Сама база, из-за размера, будет открываться по-другому, но работать должно с одинаковой скоростью. Исключение - первое выполнение. С MDE не экспериментировал - не нужно было, поэтому судить не берусь. Могу только предположить, что MDE содержит и текстовый, и предкомпилированный варианты запроса. > 2. Попытайтесь вызывать из SQL функцию (конвертор цены в текст) на русском языке - будут ошибки, но не сразу (надо редактировать формы, еще что-то делать ...). Это проверено неоднократно. Стандартный SQL не поддерживает вызов пользовательских функций. То, что реализовала MS в Access - расширение возможностей, нигде более не поддерживаемое. Я этим стараюсь не пользоваться. > Требуется перегрузка всей базы данных или замена слов на английский текст, тогда ошибка исчезает. Не сталкивался - нормально работаю на английском. А вот с чем сталкивался, так это с такой шуткой. В одной из таблиц есть пользовательское поле с названием TableID (так по задаче было удобно). Поле нормально создается. Без проблем можно модифицировать его содержимое в табличном режиме. Выборка тоже происходит нормально. А вот при модификации SQL-запросами выдается ошибка... Пару дней возился, пока не выяснил, что дело именно в названии этого поля. > Категорически не советую в больших базах использовать функции на русском языке. Даже в маленьких. > В локальных версиях всегда ошибок больше из-за различных кодировок символов. Больше проблем с локализацией, а не ошибок из-за различных кодировок. > 3. Давно известно, что корректно обрабатываются компилятором, а именно, ключевые слова (не данные) состоящие из символов от 32-127 символов, посмотрите на htm - страницы (примеров много), т.к. другие могут восприниматься как управляющие символы. Перечитайте это еще раз. Компилятор либо примет строку символов - если она удовлетворяет грамматике используемого языка, либо выдаст ошибку. За качество диагностики не ручаюсь - сильно зависит от разработчика. Но за что ручаюсь, так это за то, что скорость работы лексического анализатора компилятора не зависит от того, какие именно символы поступают на вход. Лишь бы удовлетворяли языку. Размер анализатора - другой вопрос. P.S. Виктор Конюков. Для тех, кто интересуется как работает компилятор советую посмотреть книгу Д. Хендрикс "Компилятор языка СИ для микроЭВМ", перевод с английского А.А. Батнера под редакцией Б.А. Кузьмина (Москва, "Радио и связь", 1989, 238 стр.). Исходные тексты прилагаются. |