Насмотревшись на цитаты проектов и куски кодов возник вопрос как выводят все эти несусветные наименования полей в интерфейс клиентов. Я наверно чего-то не знаю, может быть принято в каждой БД иметь таблицу namespace или типа того. Такого рода примеров по сети не встречал и подозреваю что преобразование осуществляется приложением, то есть приложение начинает слишком много знать о БД и становится частью БД.

Например есть талицы customer(id, country_id, name); country(id, title);

Как вы покажете в интерфейсе отчет? Получается что так:

customer: Иван Иванов
country: Россия

Чтобы сделать нормально, придется сообщить скрипту все необходимое. В синтаксисе php например:


или


где $rst->country - переменная country со значением названия страны.

Но откуда вы знаете что country - страна? Посмотрели в словаре. Прекрасно. А если поле называется custappstoregoods097. Таких слов не бывает. Получается надстройка над БД в виде девелопера который единственный кто знает что к чему между БД и приложением.

Я понимаю это способ унасекомить клиента. Посмотрев в БД он внезапно поймет что без вечной славы девелоперу не обойтись, а значит дети девелопера не будут голодать.

А на самом ли деле все именно так? Я думаю что все наоборот. Чем страшнее выглядят БД в натуре и коды изнутри, тем меньше клиентов которые бы пожелали себе такое счастье - попасть в сети к девелоперу навечно. Кроме того проектировщик сам страдает, теряет время и силы на преодоление нелепых трудностей перевода.

Кроме того вдруг найдется девелопер который решит что пора уже упрощать и отберет всех клиентов не менее внезапно?

Чтобы сделать нормально

Покупатель: Иван Иванов
Страна: Россия

Надо назвать поля по смыслу и по-русски и вывести так. Я выбрал синтаксис ms-vb как самый очевидный.


В этом случае скрипт вообще ничего не знает о БД кроме того, что там есть запись, и есть поле с индексом 0.

Можете возразить что про 0 все равно надо знать, потому что где 0 там имя, а где 1 там страна.

Возразить нельзя. Все что требуется вывести определяется не в скрипте, а в самом запросе. Скрипт просто выведет все что получит в цикле перечисления полей и значений. Если не требуется выводить поле Страна исключите его из запроса и скрипт выведет единственную запись единственного поля.

Покупатель: Иван Иванов.

Дальше хуже. Как вывести таблицу в таблицу, если в названиях полей таблицы тарабарщина? Каждому запросу сопоставлять индивидуальный шаблон?

Да, не rst.field(0), но rst.fields(0) конечно.

Давая таблицам и полям кодированные имена девелопер первым делом унасекомит сам себя. Имя поля превращается в код поля. Соответствие кода - имени прописывается в исходном тексте приложения. Что совершенно однозначно является нарушением заповедей Кодда.

Еще можно возразить что названия таблиц и полей как правило редко отображаются в интерфейсе. Так потому и редко, что затрахаешься переводить на человеческий язык. Разраб попросту избегает этой задачи и вместо

Покупатель: Иван Иванов
Страна: Россия

выводит

Иван Иванов
Россия

Понятно же и так что где. Нет же покупателя Россия и страны Иван Иванов.

Вполне понятно откуда растет идиосинкразия к кириллице и я двумя руками за то, чтобы перейти на латиницу. Mnogestvo nashih sorodichey pishut latinskimi bukvami no pochti po-russki. Однако вряд ли такое возможно в ближайшие 200 лет, поэтому придется пользоваться контрафактным алфавитом (Киря и Мифа наш алфавит попросту натырили).

Но самое смешное что большинство разрабов которые кодируют таблицы и поля типа английскими словами - по-английски вообще не читают.

Начинайте проект сразу в юникоде, проверяйте все настройки и кодировки на юникод и абсолютно никаких проблем с кириллицей не будет.

Поскольку я насмотрелся, то могу сказать что делается в основном так (на пхп)




Вся эта шняга записывается в файл с именем типа customeraddress.tpl.php и затем подгружается в нужном месте include();

Чтобы вывести форму для всех этих полей пишется еще один шаблон, или крайне хитромудро модифицируется предыдущий в зависимости от значений какой-нить переменной. Еще можно токенизировать и разработать уже свой собственный мета-язык который бы снабжал результат запроса той или иной формой. Это при том что стопицот лет назад уже разработаны xml и xslt.

Если же имена таблиц и полей можно юзать напрямую, без кодирования, то никаких самокатов изобретать не придется.




Простейший код который выведет таблицу из 2 столбцов повернутую на бок: названия полей слева в строках. Это самый распространенный вид вывода сведений о сущности, скажем о товаре где слева название свойства, справа значение свойства.

Чтобы вывести таблицу типа отчета с названиями полей в столбцах надо прописать отдельно генерацию заголовков и строк.




И вот сравните что имеет разраб за кодирование названий таблиц и полей - неуправляемую кучу шаблонов на все случаи жизни и варианты запросов, и что имеет разраб когда именует таблицы и поля напрямую - одну функцию в дюжину строк. Хотя бы даже и по-английски, но нормальными словами и фразами.

Чтобы вывести форму с полями ввода используется та же самая функция. Внутрь ячеек запихиваются input'ы всякие. Кроме того через объект $col можно узнать много полезного для правильной генерации полей ввода и для проверки чего там юзер ввел. fetch_field дает кучу инфы.

На других языках полагаю будет точно так же.

И про indentity. Это вообще может показаться кощунством, но если вы начнете напрямую именовать таблицы и поля на русском языке, то и все эти id можно превратить в слово код.

В жизни мы запросто говорим код города, код товарной номенклатуры (ТН ВЭД, которые на самом деле КТН УВЭД), так что и с кодами в таблице не должно быть проблем.

Кстати, имея нормальное имя таблицы его можно вывести в caption:


Для целей адекватного отображения полей и контроля за целостностью данных функция

http://www.php.net/manual/en/mysqli-result.fetch-field.php

дает практически все необходимое. Только вот почему-то COMMENT забыли включить в сборник.

Варианты типа запузырить нормальные псевдонимы во все кодированные имена полей в запросах конечно имеют право на жизнь, но тогда возникает вопрос: ради чего кодировать имена вообще?

Вопрос отображения данных освещен со стороны веб-технологий потому что в нормальных языках такого вопроса не существует. Там давно разработаны объекты типа datagrid и любой элемент управления можно тупо связать с любым полем щелчком мыши. Выводить вручную конечно можно тоже, но кто это делает кроме конченых?

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

Конечно можно вообще без кодов обойтись воспользовавшись функцией CONCAT();

И последнее, потребуется backticks. Независимо от языка, если поля называются нормально, то они будут из двух, а то и трех слов типа Имя пользователя, Название магазина.

К сожалению ` на клаве заведен с буквой ё, что немедленно заколебет если поля на русском. Проще будет обучить свой текстовый редактор вставлять backticks по нажатию этой клавиши независимо от раскладки клавы. НоутпадПлюс это умеет.

Конечно ё уже не удасться ввести. Думаю небольшая потеря.

Бредятина,

Я же показал пример такой СУБД выше. Метаданные описываются в мириадах шаблонов, шаблоны учитываются в БД, надо полагать тем же способом и конца края этому разгулу спящего разума нет.

Ну хорошо, а что дает кодирование названий таблиц и полей?

Дело ведь не в том что вы даете названия типа Product, Category, Catalog, Report и тому подобные. Ну пожалуйста пишите по-английски, никто не запрещает делать англоязычный интерфейс.

Но какой практический смысл в именах типа supplonehaveadog095?

Я пытался доказать что проблема в том, что бдями занимаются программисты. Они так привыкли и это нормально. Никакой нормальный программист не будет давать переменным публичные имена, хотя самые вменяемые не ленятся и называют типа counter_that_control_over_this_cycle. Программист как писал int cnt, так и поля с таблицами назовет.

Потому что для него БД это всего лишь такая большая-большая переменная объектного типа. Врубаться в отношения и во все остальное в чем смысл БД программист не будет.

Мы в рубрике проектирование БД и я просто хотел показать как не надо проектировать, и как надо. На самом примитивном уровне, с которого все и начинается.

Программист относится к БД так же, как слесарь к автомобилю, к которому совсем по-другому относится инженер, коими и являются читатели данной рубрики. Не уподобляйтесь слесарям которые только и умеют что курочить что инженер создал. Создавайте.

Насчет метов. Интересное явление. mysqli fetch_field не возвращает COMMENT поля. Программисты делали объект.

sp,

Я главного не пойму - где возражения? Единственный предыдущий читатель чем-то таким напугал, но не до конца.

Дело же не в том что поля по-русски или по-китайски названы. Дело в том что у многих это не названия, а некие коды, смысла в которых без комментариев не поймешь.

Грубо говоря каждая программистская башка говорит на своем языке. Эффективность коммунити стремиться к нулю, растет обособление, окукливание, ошмукливание и в итоге отсталость.

Я этот форум нашел случайно. Дай думаю почитаю на родном что пишут о модели nested set. Блин, практически ровно одна статья на весь рунет - и она тут! Это разве не отсталость?

Прекрасно знаю что программисты во всем мире по упертости вторые после шоферни, но мы, самые упертые наверное.

Я тут портянки пишу, а хоть бы кто пришел и как следует напугал. Типа вот напишешь вместо wholepriceonagent007 нечто типа `Whole Price on Agent 007` и капец твоей датабазе.

Разве никому тут не приходилось править чужие коды? Да я и свои-то могу после четверти часа раздумий как мне такое удалось наворотить. Пройдет полгода и сырец без комментариев с халявными названиями переменных становится чужим. Ключевое слово тут - халява. Кавычки не ставить, понимаешь, это удобно. Один чел на переполненном стеке так прямо и заявил что backtick'и делают его коды поломатыми.

Но откройте любую публичную библиотеку из репозитория куда грамотные люди принимают только удобоваримые куски и почувствуйте вкус настоящей халявы позднего связывания.

Халява раннего связывания приводит к несварению.

Dimitry SibiryakovСамое забавное, что в любом сервере БД уже изначально есть база метаданных, которая
называется "словарь".


Одуреть. И что, этот словарь может перевести содержание этого сообщения? Или в чем разница между содержанием и формой по-вашему?

Ну назову я поле onedaywhenworldwilldie, сопоставлю фразе и что это мне даст такого, чего я не могу получить назвав поле `One day when world will die`?

Это что, на самом деле таков масштаб бедствия с кавычками, что ради их отсутствия люди словари заводят в бд?

Словари существуют чтобы переводить с одного языка на другой. Когда язык не детерминирован, какой в одно место может быть перевод?

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

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

Не процедурно - системно. Предусмотреть в интерфейсе отсутствие потребности в нижнем подчеркивании и заменить его символ в системном шрифте на пробел. :)

Напомню господам инженерам что тема не про технику, а про культуру!

Однако без техники культуры не бывает. Все искусства возникли в результате технического прогресса.