ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оперативный файл и справочники. Автоматизация запросов.
25 сообщений из 154, страница 3 из 7
  3  все
Оперативный файл и справочники. Автоматизация запросов.
    #35581980
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
kordaПервое, что бросается в глаза при просмотре сгенерированного
запроса, приведенного выше - это невообразимо длинные и трудночитаемые имена
полей.

kordaИсходя из всего вышесказанного приходят на ум две вещи:

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

2. Эти описания результатов запросов должны содержать ссылки на ключи в
текстовом файле (на стороне клиента), который ответственен за трансляцию
текстов на разные языки. Кроме таких ссылок описание может содержать имя
используемое в качестве алиса поля в результирующем view.

Таким образом имена полей не будут представлять собой (как это имеет место
быть в приведенном выше примере) генерируемые строки, а будут частью
метаданных, которые будут поставляться генератору. Естественно, в этом
случае возникает проблема уникальности алиаса. Нужно будет "вручную"
следить, чтобы алиасы не "перекрывали" друг друга при генерации
результирующего запроса, что не есть хорошо. Может быть у кого-нибудь есть
идея лучше?

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

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
08.10.2008, 08:02
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35582189
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Valentin Kotelnitski
Да, надо выводить дружелюбные названия полей. И все равно при этом подходе
слишком много полей - неудобно получается.


С Вашим замечанием трудно несогласиться... Вы знаете, Вы натолкнули меня на мысль, что вобщем-то, я не обязан выдавать пользователю ВСЕ поля. Как я уже писал ранее, у пользователя будет возможность выбирать для показа ЛЮБЫЕ поля из ЛЮБОЙ связанной таблицы. Я вот подумал, что возможно в таблице будут присутствовать всякие "технические" поля, используемые внутренней бизнес-логикой приложения, и это даже полезно, что я смогу сделать так, что эти поля будут скрыты не только для пользователя GUI, но и для проектировщиков систем отчетов и визуализации. Таким образом, я получу возможность управлять структурой выдаваемого результата .
...
Рейтинг: 0 / 0
08.10.2008, 10:08
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35582311
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
korda
Первое, что бросается в глаза при просмотре сгенерированного запроса, приведенного выше - это невообразимо длинные и трудночитаемые имена полей.

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

Конкретно, если есть таблицы MAN, STREET, CITY, у каждого из них есть NAME, и нужно вывести человека с полным адресом, то как назвать каждое из NAME в результате?

Здесь помог бы осуждаемый многими принцип, когда краткий идентификатор таблицы участвует в названии всех ее полей, например MAN_ID, MAN_NAME, STR_NAME, CITY_NAME. Это позволило бы сохранить уникальность названий полей в результате без переименования алиасами в большинстве случаев.

Необходимость алиасов останется в случае множественных ссылок на один справочник, и циклических ссылок. Например, таблица DOC, и три ссылки на один справочник MAN - "Составил", "Проверил", "Утвердил". Это можно формализовать тем, что именовать множественные ссылки явно, и использовать этот идентификатор как суффикс во всех необходимых случаях.

Назовем эти ссылки DRAW, CHK, CONF. В таблице DOC FK-поля будут MAN_ID_DRAW, MAN_ID_CHK, MAN_ID_CONF. В SQL-запросе таблица MAN будет участвовать трижды, пусть она имеет алиасы MAN_DRAW, MAN_CHK, MAN_CONF. Все поля, принятутые из MAN и дальнейших справочников, пусть тоже получают суффикс - MAN_NAME_DRAW, MAN_NAME_CHK...

Если потребовать уникальности названий всех полей и всех идентификаторов множественных ссылок в пределах БД, а еще соблюдение условия префиксности в названиях, то не представит труда автоматический разбор названия алиаса, и составление русского названия из описателя. Например, если ивестно, что "MAN_NAME" - "ФИО", "CHK" - "Проверил", то MAN_NAME_CHK будет "Проверил.ФИО". Такая точечная нотация в 80% случаев удовлетворительна для понимания смысла графы.

Для оставшихся 20% необходим механизм ручного именования сложных полей, например указать что
MAN_NAME_CHK = "ФИО проверяющего", и это указание должно иметь высший приоритет, чем автоматически составленное имя.

То есть напрашивается описатель всех полей, таблиц, идентификаторов ссылок, и некоторых сложных полей с русскими названиями.
...
Рейтинг: 0 / 0
08.10.2008, 10:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35582445
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
korda я не обязан выдавать пользователю ВСЕ поля.

Верно. Я бы сразу попробовал выделить в каждой таблице, использующейся как справочник, набор полей, уникально идентифицирующих запись с точки зрения пользователя, выбирающего запись из справочника. Так сказать, "Пользовательский естественный ключ". Например, для MAN это может быть ФИО и табельный номер. Тогда в запросах "для справочника" можно будет ограничиться этими полями. Отметку "Показывать в справочнике" уместно поставить в том же описателе полей, о котором я уже говорил.

Вообще, советую еще раз прислушаться к мнению, что задача эта достаточно сложна. И сложность ее заключается не столько в генераторе SQL-кода. Это, в сущности, самая легкая ее часть, в том плане что она строго формализуется. Основная сложность задачи в том, что поведение системы в значительной степени перестает управляться "прикладным" программным кодом, а начинает управляться "супер-ядром" со всякими декларативными таблицами, флажками, описателями и т.д. И поведение это пронзает всю систему, от структуры БД и SQL-кода до логики клиента и визуальных элементов - Вы ведь со временем и гриды заходите автоматически делать, и формы для редактирования, и для фильтрации, и типовые отчеты автоматизировать. Это ведь тоже "рутина", как и SQL-код. И самое интересное, что все это возможно. Но если изначальная модель приложения была недостаточно продумана, то декларативное поведение по умолчанию становится тесным и неуместным в 10-20% непредусмотренных "особых" случаев, на борьбу с которыми уходит много времени - либо переделывай все генераторы и включай глобальную поддержку особых фич, либо мирись с неудобством автоматического интерфейса. Так что советую еще раз сесть и написать, сколько фич Вам нужно для полного счастья.

korda
Как я уже писал ранее, у пользователя будет возможность выбирать для показа ЛЮБЫЕ поля из ЛЮБОЙ связанной таблицы.

Вот тут я бы с осторожностью отнесся. Выбирать поля для показа должен проектировщик. А пользователь, раз уж он хочет - из выбранного проектировщиком, как дополнительная опция. А то получится новый Access, когда сделать можно все, но для этого нужно быть программистом.
...
Рейтинг: 0 / 0
08.10.2008, 11:21
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35582578
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Cane Cat FisherВот тут я бы с осторожностью отнесся. Выбирать поля для показа должен проектировщик. А пользователь, раз уж он хочет - из выбранного проектировщиком, как дополнительная опция. А то получится новый Access, когда сделать можно все, но для этого нужно быть программистом.+1
...
Рейтинг: 0 / 0
08.10.2008, 11:45
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35582597
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
2Cat Fisher?
Счастье мое, запутаешься. Да, это правда, что скорее всего документы
утверждает PERSON, его конечно можно его перепутать с MAN.
2korda
Никому не нужен твой суперзапрос. Ты просто не въезжаешь. Юзеры тебя
проклинать будут.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
08.10.2008, 11:49
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583604
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
2 Cane Cat Fisher
На данном этапе я использую именно такой, как Вы предложили принцип формирования имен алиасов.
Просто иногда мало знать из какой таблицы "пришло" поле, нужно еще знать всю историю "наследования" поля от "первородных таблиц" и до результата, своеобразный path. Знание этого path, позволяет в точности представлять с данными какого именно поля мы имеем дело.
Что касается того, что часть названий полей может быть сгенерирована автоматически, а часть (случай нескольких ссылок на одну и ту же таблицу) - вручную, то мне кажется, что стоит избрать единый метод - или все автоматически, или все - вручную, ведь и без того декларативных вещей здесь не мало.
...
Рейтинг: 0 / 0
08.10.2008, 16:08
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583638
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
"...поведение системы в значительной степени перестает управляться "прикладным" программным кодом, а начинает управляться "супер-ядром" со всякими декларативными таблицами, флажками, описателями и т.д."

Cane Cat Fisher


P.S. Мне ужасно понравилось это высказывание, поэтому я решил выделить его особо... Оно очень точно, на мой взгляд, передает суть проблемы.
Проблема больше философская или даже психологическая, чем техническая. Хотя, лично для меня, это и технически достаточно сложно.
...
Рейтинг: 0 / 0
08.10.2008, 16:19
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583697
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
korda...мне кажется, что стоит избрать единый метод - или все автоматически, или все - вручную, ведь и без того декларативных вещей здесь не мало.

Спасибо за цитирование меня такими крупными буквами :-)

Я не зря настаиваю на сочетании автоматических и ручных методов. Более того, осмелюсь предложить для крупноформатного цитирования еще одну мысль: главный вопрос нашей револю... тьфу, подобной системы - вопрос об оптимальном сочетании автоматического и ручного кода. Ибо ручной код без автоматического, как Вы заметили, рутинен и трудоемок. А автоматический без ручного - туп и никому не нужен в чистом виде, потому что получается просто SQL-обозреватель таблиц безо всякой бизнес-логики. В генераторе SQL-кода обязательно нужны "места", через которые можно вмешаться в логику работы, и добиться нестандартного результата. Яркий пример - вычисляемые поля. Например, в связке MAN - STREET - CITY напрашивается вычисляемое строковое поле "Адрес человека", где будут слеплены что-то вроде тип населенного пункта + название + тип улицы + название улицы + дом + корпус + квартира. Сам генератор до этого не додумается, а показать эту россыпь полей по отдельности будет дубово. Поэтому нужны или обработчики событий ядра вроде OnDefineCalcField, или какие-то компоненты - представители отдельных таблиц со своими свойствами и обработчиками, или какое-то наследование с виртуальными методами.
...
Рейтинг: 0 / 0
08.10.2008, 16:42
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583705
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
"Пользовательский естественный ключ" (в терминологии Cane Cat Fisher)

Кажется мне, что если сппроектировать правильно структуру БД и интерфейс пользователя, то естественный ключ может(и должен) быть одним полем. В справачнике работников - это табельный номер, в справочнике операций - название операций, в случае оперативных таблиц это может быть точным временем создания записи. (Сейчас я автоматически считаю первое (после "технических" полей), поле каждой таблицы "пользовательским естественным ключом").
Я не уверен на сто процентов в правильности этой концепции. Может быть она ошибочна?
...
Рейтинг: 0 / 0
08.10.2008, 16:45
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583748
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
korda
Кажется мне, что если сппроектировать правильно структуру БД и интерфейс пользователя, то естественный ключ может(и должен) быть одним полем. В справачнике работников - это табельный номер

Немного не так. Под "пользовательским естественным ключом" (возможно, название не совсем удачно) я имел в виду набор полей, уникально идентифицирующих запись с точки зрения пользователя, выбирающего запись из справочника . Другими словами, табельный номер - несомненно, хороший естественный ключ с точки зрения теории БД, но если для выбора человека из справочника выкатится только лишь табельный номер, то оператор будет огорчен. Ему нужны ФИО. А табельный номер - в дополнение, для разрешения коллизий по тезкам, ну и еще для кадровиков пенсионного возраста, которые помнят тысячу человек по табельным номерам.

Так что одним полем не обойдетесь.
...
Рейтинг: 0 / 0
08.10.2008, 16:59
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583880
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher korda
Кажется мне, что если сппроектировать правильно структуру БД и интерфейс пользователя, то естественный ключ может(и должен) быть одним полем. В справачнике работников - это табельный номер

Немного не так. Под "пользовательским естественным ключом" (возможно, название не совсем удачно) я имел в виду набор полей, уникально идентифицирующих запись с точки зрения пользователя, выбирающего запись из справочника . Другими словами, табельный номер - несомненно, хороший естественный ключ с точки зрения теории БД, но если для выбора человека из справочника выкатится только лишь табельный номер, то оператор будет огорчен. Ему нужны ФИО. А табельный номер - в дополнение, для разрешения коллизий по тезкам, ну и еще для кадровиков пенсионного возраста, которые помнят тысячу человек по табельным номерам.

Так что одним полем не обойдетесь.

Нет, гооря о пользовательском естественном ключе я имел ввиду UNIQUE поле, которое, с точки зрения пользователя однозначно идентифицирует запись. Вы же, как я понял, под этим термином понимаете некий минимальный набор полей, предоставляемый пользователю по умолчанию. Такой набор - понятие субъективное и, наверное, не существует четких критериев, какие поля - да, должны быть предоставлены, а какие - нет.
...
Рейтинг: 0 / 0
08.10.2008, 17:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35583911
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaВы же, как я понял, под этим термином понимаете некий минимальный набор полей, предоставляемый пользователю по умолчанию. Такой набор - понятие субъективное и, наверное, не существует четких критериев, какие поля - да, должны быть предоставлены, а какие - нет.Но это не мешает проектировщику установить этот набор полей для разных объектов.

Для адреса: REGION, CITY, STREET, HOUSE
Для персоны: FIRST_NAME, MID_NAME, LAST_NAME
Для телефона: CITY_CODE, PHONE, PHONE_TYPE
итд. итп.

А далее эти наборы использовать для отображения в гриде, например.
Если пристыковываем человека, то отображаем три поля ФИО.
Если пристыковываем телефон, то код города, тедлефон, добавочный

Для стандартных спраочников - отображаем одно поле NAME
...
Рейтинг: 0 / 0
08.10.2008, 17:47
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584084
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
korda Вы же, как я понял, под этим термином понимаете некий минимальный набор полей, предоставляемый пользователю по умолчанию. Такой набор - понятие субъективное и, наверное, не существует четких критериев, какие поля - да, должны быть предоставлены, а какие - нет.

Да, именно так. И именно поэтому эта часть работы не может быть отдана на откуп автомату, или какому-то общему алгоритму, а требует явного указания, как часть проектирования системы.
...
Рейтинг: 0 / 0
08.10.2008, 18:47
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584336
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Bely kordaВы же, как я понял, под этим термином понимаете некий минимальный набор полей, предоставляемый пользователю по умолчанию. Такой набор - понятие субъективное и, наверное, не существует четких критериев, какие поля - да, должны быть предоставлены, а какие - нет.Но это не мешает проектировщику установить этот набор полей для разных объектов.

Для адреса: REGION, CITY, STREET, HOUSE
Для персоны: FIRST_NAME, MID_NAME, LAST_NAME
Для телефона: CITY_CODE, PHONE, PHONE_TYPE
итд. итп.

А далее эти наборы использовать для отображения в гриде, например.
Если пристыковываем человека, то отображаем три поля ФИО.
Если пристыковываем телефон, то код города, тедлефон, добавочный

Для стандартных спраочников - отображаем одно поле NAME

Именно этого я и хочу. Правда, с небольшим добавлением. Пользователь сможет, свободно скрывать, добавлять, менять местами поля, в том числе, разумеется, и те, которые, которые выбраны разработчиком, как поля по умолчанию. Эти манипуляции с полями происходят на уровне GUI, а из таблиц "тянется" всё.
...
Рейтинг: 0 / 0
08.10.2008, 22:41
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584347
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Перечитал я тут, на досуге, последнюю переписку, в частности, Cane Cat Fisher пишет о вычисляемых полях. Это ещё один, неучтенный мной подводный камень... С вычисляемыми полями, черт возьми, даже не знаю что и делать. У меня задаются метаданные по каждой таблице, на основе этих данных строятся CREATE TABLE и CREATE VIEW , т.е. я примерно представляю, как описать физические поля, но как описать виртуальные, учитывая, что они как правило функция от нескольких физических... Если я начну поддерживать такие сложные (сложные в своем описании) вещи, то я просто не выберусь из этой задачи. По крайней мере на данный момент я не вижу никакого более-менее приемлемого решения.
...
Рейтинг: 0 / 0
08.10.2008, 22:53
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584358
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaИменно этого я и хочу. Правда, с небольшим добавлением. Пользователь сможет, свободно скрывать, добавлять, менять местами поля, в том числе, разумеется, и те, которые, которые выбраны разработчиком, как поля по умолчанию. Эти манипуляции с полями происходят на уровне GUI, а из таблиц "тянется" всё.Не знаю как вы, а я редко встречал пользователей, которые бы сами меняли набор полей, даже если это можно сделать.

Как правило все сводится к тому, что отображаются либо все поля какие есть в наличии, либо те, которые выбраны по умолчанию.
...
Рейтинг: 0 / 0
08.10.2008, 23:03
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584364
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Пока суть, да дело, работал над названиями алиасов.

Имеем два случая:

1. Поле из основной таблицы:
ИМЯ_ТАБЛИЦЫ__ИМЯ_ПОЛЯ

2. Поля из прилинкованных таблиц (справочников):
ИМЯ_ОСНОВНОЙ_ТАБЛИЦЫ__ИМЯ_КЛЮЧА_ПО_КОТОРОМУ_ОСНОВНАЯ_ТАБЛИМЦА_СВЯЗАНА_СО_СПРАВОЧНИКОМ__ИМЯ_СПРАВОЧНИКА__ИМЯ_ПОЛЯ

"__" - разделитель.
...
Рейтинг: 0 / 0
08.10.2008, 23:08
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584374
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Результат выдается теперь в следующем виде (не для чтения!)

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE VIEW W_WORKPLACE2 AS SELECT 
T0.ID AS V_WORKPLACE2__ID
,T0.TIME_S AS V_WORKPLACE2__TIME_S
,T0.TIME_E AS V_WORKPLACE2__TIME_E
,T0.USER AS V_WORKPLACE2__USER
,T0.TYPE AS V_WORKPLACE2__TYPE
,T0.ZAVAL_ID AS V_WORKPLACE2__ZAVAL_ID
,T1.ID AS V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__ID
,T1.TIME_S AS V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_S
,T1.TIME_E AS V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_E
,T1.USER AS V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER
,T1.SIZE AS V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__SIZE
 FROM V_WORKPLACE2 AS T0
 LEFT JOIN W_ZAVAL AS T1 ON (T1.ID=T0.ZAVAL_ID)


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
CREATE VIEW W_PERSON AS SELECT 
T0.ID AS V_PERSON__ID
,T0.TIME_S AS V_PERSON__TIME_S
,T0.TIME_E AS V_PERSON__TIME_E
,T0.USER AS V_PERSON__USER
,T0.NAME AS V_PERSON__NAME
,T0.AGE AS V_PERSON__AGE
,T0.WORKPLACE1_ID AS V_PERSON__WORKPLACE1_ID
,T0.WORKPLACE2_ID AS V_PERSON__WORKPLACE2_ID
,T0.WORKPLACE2_TWO_ID AS V_PERSON__WORKPLACE2_TWO_ID
,T0.OTHER_PERSON_ID AS V_PERSON__OTHER_PERSON_ID
,T1.ID AS V_PERSON__WORKPLACE1_ID__W_WORKPLACE1__ID
,T1.TIME_S AS V_PERSON__WORKPLACE1_ID__W_WORKPLACE1__TIME_S
,T1.TIME_E AS V_PERSON__WORKPLACE1_ID__W_WORKPLACE1__TIME_E
,T1.USER AS V_PERSON__WORKPLACE1_ID__W_WORKPLACE1__USER
,T1.TYPE AS V_PERSON__WORKPLACE1_ID__W_WORKPLACE1__TYPE
,T2.V_WORKPLACE2__ID AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ID
,T2.V_WORKPLACE2__TIME_S AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__TIME_S
,T2.V_WORKPLACE2__TIME_E AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__TIME_E
,T2.V_WORKPLACE2__USER AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__USER
,T2.V_WORKPLACE2__TYPE AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__TYPE
,T2.V_WORKPLACE2__ZAVAL_ID AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__ID AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__ID
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_S AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_S
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_E AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_E
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__SIZE AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__SIZE
,T3.V_WORKPLACE2__ID AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ID
,T3.V_WORKPLACE2__TIME_S AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__TIME_S
,T3.V_WORKPLACE2__TIME_E AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__TIME_E
,T3.V_WORKPLACE2__USER AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__USER
,T3.V_WORKPLACE2__TYPE AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__TYPE
,T3.V_WORKPLACE2__ZAVAL_ID AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID
,T3.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__ID AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__ID
,T3.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_S AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_S
,T3.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_E AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__TIME_E
,T3.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER
,T3.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__SIZE AS V_PERSON__WORKPLACE2_TWO_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__SIZE
,T4.ID AS V_PERSON__OTHER_PERSON_ID__V_PERSON__ID
,T4.TIME_S AS V_PERSON__OTHER_PERSON_ID__V_PERSON__TIME_S
,T4.TIME_E AS V_PERSON__OTHER_PERSON_ID__V_PERSON__TIME_E
,T4.USER AS V_PERSON__OTHER_PERSON_ID__V_PERSON__USER
,T4.NAME AS V_PERSON__OTHER_PERSON_ID__V_PERSON__NAME
,T4.AGE AS V_PERSON__OTHER_PERSON_ID__V_PERSON__AGE
,T4.WORKPLACE1_ID AS V_PERSON__OTHER_PERSON_ID__V_PERSON__WORKPLACE1_ID
,T4.WORKPLACE2_ID AS V_PERSON__OTHER_PERSON_ID__V_PERSON__WORKPLACE2_ID
,T4.WORKPLACE2_TWO_ID AS V_PERSON__OTHER_PERSON_ID__V_PERSON__WORKPLACE2_TWO_ID
,T4.OTHER_PERSON_ID AS V_PERSON__OTHER_PERSON_ID__V_PERSON__OTHER_PERSON_ID
 FROM V_PERSON AS T0
 LEFT JOIN W_WORKPLACE1 AS T1 ON (T1.ID=T0.WORKPLACE1_ID)
 LEFT JOIN W_WORKPLACE2 AS T2 ON (T2.V_WORKPLACE2__ID=T0.WORKPLACE2_ID)
 LEFT JOIN W_WORKPLACE2 AS T3 ON (T3.V_WORKPLACE2__ID=T0.WORKPLACE2_TWO_ID)
 LEFT JOIN V_PERSON AS T4 ON (T4.ID=T0.OTHER_PERSON_ID)
...
Рейтинг: 0 / 0
08.10.2008, 23:14
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584501
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
kordaРезультат выдается теперь в следующем виде (не для чтения!)
Код: plaintext
1.
...
бедный сопровод, как же я ему не завидую....
...
Рейтинг: 0 / 0
09.10.2008, 00:55
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584732
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
egorych kordaРезультат выдается теперь в следующем виде (не для чтения!)
Код: plaintext
1.
...
бедный сопровод, как же я ему не завидую....

А с какими именами полей Вы бы позавидовали? Как назвать поле, которое "унаследовано" от справочника n -го уровня?
Существует ещё один метод именования полей. Давать каждому полю серийный номер, уникальный, в рамках системы.
Тогда имена полей будут значительно короче, например A2441 , но поможет ли это сопровождению?
Вобщем, мое сознание мечется между этими двумя методами. Ах, если бы можно было задать комментарий для поля!... (Именно задать комментарий, хранимый в описании таблицы, а не просто комментировать поля в скрипте)

Кстати, в этом примере таблица PERSON связана с двумя справочниками WORKPLACE1 и WORKPLACE2.
При этом на WORKPLACE1 есть одна связь, а на WORKPLACE2 - две. Справочник WORKPLACE2, в свою очередь, связан со справочником ZAVAL.
Помимо этого, таблица PERSON ссылается на саму себя.

Интересно, если бы Вы писали подобный запрос "руками", как бы он выглядел?

Вообще, имена в SQL(и не только в SQL), похоже, представляют собой определенную проблему. Они должны помогать понять сущность с одной стороны и выполнять свои технические функции в рамках синтаксиса - с другой.
...
Рейтинг: 0 / 0
09.10.2008, 09:47
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35584937
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
>>> Если я начну поддерживать такие сложные (сложные в своем описании) вещи, то я просто не выберусь из этой задачи.

Описание вычисляемого поля - это его выражение (CITY.NAME || STREET.NAME || MAN.APART_NUM) и алиас (MAN_ADDR). Что здесь сложного? Другой вопрос, куда это впихнуть? А как вообще Вы представляете себе архитектуру системы? Я уже говорил, напрашиваются некие таблицы-описатели метаданных полей, по крайней мере для хранения русских названий. Вот туда впихните и описание вычисляемых полей, с соответствующим флажком.

>>> Пользователь сможет, свободно скрывать, добавлять, менять местами поля, в том числе, разумеется, и те, которые, которые выбраны разработчиком, как поля по умолчанию. Эти манипуляции с полями происходят на уровне GUI, а из таблиц "тянется" всё.

Зачем тянуть все? Порочный принцип. Если пользователю нужно быстро выбрать человека по ФИО, а в базе хранятся еще и фотки, то Вы фотки тоже будете тянуть и не показывать?

Тянуть и показывать нужно то, что нужно "в данном месте". Описать эти "места", и перечислить для каждого из них "что нужно" - это и есть проектирование. Только обычно мы делаем это созданием форм, и написанием SQL. А Вам с Вашим универсальным генератором придется выразить эту информацию в каких-то метаданных.

>>> Интересно, если бы Вы писали подобный запрос "руками", как бы он выглядел?

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

>>> Вообще, имена в SQL(и не только в SQL), похоже, представляют собой определенную проблему.

Тот, кто хочет повелевать морями, обязан знать подлинное имя каждой капельки воды в них.
...
Рейтинг: 0 / 0
09.10.2008, 10:57
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585310
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
korda egorych kordaРезультат выдается теперь в следующем виде (не для чтения!)
Код: plaintext
1.
...
бедный сопровод, как же я ему не завидую....

А с какими именами полей Вы бы позавидовали? Как назвать поле, которое "унаследовано" от справочника n -го уровня?Не знаю как назвать поле, унаследованное от источника N-ного уровня, но вот такую хрень:
Код: plaintext
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER

можно было бы просто назвать
Код: plaintext
,T2.[....] AS  WP2_ZAVAL_USER
а то что у вас получается не читаемо, не сопровождаемо. Идентификаторы слишком длинные, чтобы их принимали все подряд сервера БД.
...
Рейтинг: 0 / 0
09.10.2008, 12:43
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585556
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Bely
Не знаю как назвать поле, унаследованное от источника N-ного уровня, но вот такую хрень:
Код: plaintext
,T2.V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER AS V_PERSON__WORKPLACE2_ID__W_WORKPLACE2__V_WORKPLACE2__ZAVAL_ID__W_ZAVAL__USER

можно было бы просто назвать
Код: plaintext
,T2.[....] AS  WP2_ZAVAL_USER
а то что у вас получается не читаемо, не сопровождаемо. Идентификаторы слишком длинные, чтобы их принимали все подряд сервера БД.

Кстати, почти так оно и было до тех пор, пока именно Вы ( Bely ) обратили моё внимание(за что я весьма благодарен!:) на случаи, когда из одной таблицы происходят сразу несколько связей на другую таблицу. Таблица заказов иммет две связи таблицей адресов, так как нужен адрес заказчика и адрес исполнителя. А так как иерархия такого запроса ограничена лишь самой структурой данных, то и получаются path-подобные поля .
...
Рейтинг: 0 / 0
09.10.2008, 13:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585608
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher>>> Если я начну поддерживать такие сложные (сложные в своем описании) вещи, то я просто не выберусь из этой задачи.

Описание вычисляемого поля - это его выражение (CITY.NAME || STREET.NAME || MAN.APART_NUM) и алиас (MAN_ADDR). Что здесь сложного? Другой вопрос, куда это впихнуть? А как вообще Вы представляете себе архитектуру системы? Я уже говорил, напрашиваются некие таблицы-описатели метаданных полей, по крайней мере для хранения русских названий. Вот туда впихните и описание вычисляемых полей, с соответствующим флажком.


Сложность не в самом выражении CITY.NAME || STREET.NAME || MAN.APART_NUM, а правильно, как Вы говорите, куда его впихнуть. Но даже не в этом я вижу ОСНОВНУЮ сложность. Сейчас, какждое физическое поле представляется каким-то образом в системе метаданных. Когда я думал над этой системой, я не учел то, что указатели на описания полей могут быть использованы в выражениях. Теперь, получается, что, ели делать "по-хорошему", система метаданных должна поддерживать синтаксис этих выражений.

Что-то типа того:
Код: plaintext
1.
2.
cityColumn = new Column("CITY", Type.VARCHAR);
...
cityAddress = cityColumn.plus(streetColumn);

В подобное я точно влезать не хочу.
...
Рейтинг: 0 / 0
09.10.2008, 14:01
| Ответить | Цитировать | Написать  
25 сообщений из 154, страница 3 из 7
  3  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оперативный файл и справочники. Автоматизация запросов.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=35582578&tid=1543584]:
 0ms
get settings:
 9ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 175ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 42ms
get tp. blocked users:
 1ms
others: 231ms
total:  490ms
созд. / загр.: 490ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]