ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оперативный файл и справочники. Автоматизация запросов.
154 сообщений из 154, показаны все 7 страниц
  все  
Оперативный файл и справочники. Автоматизация запросов.
    #35573594
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Имеется некая таблица, в которой регистрируются определенные события (например: OPER -"Сделки с заказчиками").
Таблица связана со справочниками, каждый из которых в свою очередь может быть тоже связан с другими справочниками (например: CUSTOMERS - "Справочник заказчиков" связан с TOWNS - "Справочником городов")
Связи между таблицами, таким образом, образуют дерево. Инными словами БД имеет классическую структуру.
На всякий случай скажу, что ВСЕ ключи связывающие таблицу со справочниками и справочники с другими справочниками - суррогатные, одного типа, имена которых четко следуют единому правилу.

Нужно построить запрос к таблице, такой, чтобы записи результата содержали ВСЕ поля таблицы, ВСЕ поля из соответствующих справочников, ВСЕ поля справочников, связанных со справочниками и т.д.
Инными словами, хочется получить из трех таблиц OPER , CUSTOMERS , TOWNS , - таблицу с полями:
OPER.ID, OPER.DATE, OPER.CUSTOMERS_ID, CUSTOMERS.ID, CUSTOMERS.NAME, CUSTOMERS.TOWNS_ID, TOWNS.ID, TOWNS.NAME
Делается такая таблица при помощи LEFT OUTER JOIN .

Чего хотелось бы...
Описать структуру такой БД каким-то образом (DDL, XML, просто объектная древовидная модель на языке ппрограммирования, или ещё каким-то способом). Далее, дать это описание "скушать" какой-то программе, которая бы построила на его основе строку, содержащую SELECT со всеми необходимыми полями и LEFT OUTER JOIN -ами.
Естественно, такая программа должна также генерировать алиасы для каждого из полей, так как названия полей в различных таблицах могут повторяться.

Писать самому такую программу мне страшно. Или мне лишь кажется, что это не просто?
Может быть кто-то знает подобные разработки. Я понимаю, что вопросы сформулированы достаточно размыто, но может быть у кого-нибудь будут какие-то оригинальные мысли по этому поводу?
...
Рейтинг: 0 / 0
02.10.2008, 23:36
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35573811
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
Почему связи образуют дерево? А если, например, присутсвуют циклические
ссылки (для справочников-деревьев)? (Перекрестных ссылок не рассматриваем).
Зачем тебе запрос с абсолютно всеми полями. Какую практическую цель ты
преследуешь?
Описать структуру - ты же вроде как бы запроектировал уже базу на SQL?
Про конструктор запросов - почему ты считаешь, что его можно написать только
для твоей базы, а нельзя писать в общем случае?
(ты так формулируешь вопрос, что кажется, что такой запрос можно написать
только и исключительно для твоей базы).
И опять же, зачем тебе ВСЕ поля?
Может, тебе нужен графический конструктор запросов из нескольких таблиц, как
в некоторых средах RAD?
Определись с тем, что ты конкретно хочешь получить, если ты действительно
собираешься что-то писать, или тебя интересует лишь теория?

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

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

Valentin Kotelnitski
А если, например, присутсвуют циклические
ссылки (для справочников-деревьев)?

Вполне могут присутствовать. Разве это создает какие-то дополнительные проблемы?

Valentin Kotelnitski
Зачем тебе запрос с абсолютно всеми полями. Какую практическую цель ты
преследуешь?

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

Может быть интересно, почему я затеял весь этот сыр-бор с автоматизацией, вместо того, чтобы просто написать требуемый VIEW руками? Справочников может быть очень много, полей в них - тоже не мало. Да и самих оперативных таблиц - не одна. Вобщем, как я себе представляю, при необходимости добавить/удалить/изменить поле или справочник. Я погрязну в SELECT -ах состоящих возможно из сотни строк. Можно пользоваться, конечно, каким-то средством визуального проектирования, но мне ведь нужно работать с запросом из программы, а выуживть глазами поля из сгенерированного SELECT -а представляется мне неоправданно трудоемким.

Valentin Kotelnitski
Описать структуру - ты же вроде как бы запроектировал уже базу на SQL?

Ничего я ещё не запроектировал. Размышляю...

Valentin Kotelnitski
Про конструктор запросов - почему ты считаешь, что его можно написать только
для твоей базы, а нельзя писать в общем случае?
(ты так формулируешь вопрос, что кажется, что такой запрос можно написать
только и исключительно для твоей базы).


Нет, Вам показалось :)
Я бы очень не хотел решения, которое основано на уникальных особенностях какой-то конкретной БД.

Valentin Kotelnitski
И опять же, зачем тебе ВСЕ поля?


Не мне, а пользователю)))

Valentin Kotelnitski
Может, тебе нужен графический конструктор запросов из нескольких таблиц, как
в некоторых средах RAD?


Это идея. Но я хотел бы предоставить пользователю готовые GUI-таблицы, так как у него нет ни времени, ни желания, ни знаний для проектирования реляционных запросов, пусть даже в дружественной среде специально созданного для этого интерфейса.

Valentin Kotelnitski
Определись с тем, что ты конкретно хочешь получить, если ты действительно
собираешься что-то писать, или тебя интересует лишь теория?

Собираюсь писать... Теория интересует лишь в той степени, в которой она способна помочь в практике.
...
Рейтинг: 0 / 0
03.10.2008, 10:14
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574161
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
Надо хорошо подумать, какой набор полей нужен пользователю и написать
запрос.
Для этого хорошенько его расспросить. В этом и заключается твоя работа.
Запрос строится исходя из объективных потребностей заказчика.
Наверняка он не должен сам конструировать запрос с необходимыми ему полями
каждый раз, когда захочет увидеть, что же ему нужно.
Лишние поля ему тоже не нужны. Показываем пользователю только то, что он
должен увидеть, чтобы принять решение.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
03.10.2008, 11:02
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574188
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaОписать структуру такой БД каким-то образом (DDL, XML, просто объектная древовидная модель на языке ппрограммирования, или ещё каким-то способом). Далее, дать это описание "скушать" какой-то программе, которая бы построила на его основе строку, содержащую SELECT со всеми необходимыми полями и LEFT OUTER JOIN -ами.
Естественно, такая программа должна также генерировать алиасы для каждого из полей, так как названия полей в различных таблицах могут повторяться.
kordaЦель практическая. GUI-клиент отображает таблицу операций, которая связана со многими справочниками. Пользователь хочет видеть сразу не только реквезиты самой операции, но и реквезиты заказчика и то, в каком городе заказчик находится. Или, например, отсортировать операции по городу заказчика или по региону, которые суть находятся не в основной таблице, а в справочниках.Ну что сказать...
Все мне известные попытки написания таких программ - ни к чему хорошему не привели.

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

Самое трудное в программировании - это не составить запрос (или 10 запросов), а ПОНЯТЬ что надо показать пользователю. Написать запрос с JOIN-ами для всех таблиц - ну максимум пару дней. А вот понять что именно надо пользователю для ЭФФЕКТИВНОЙ работы - тут приходится голову ломать всем.
...
Рейтинг: 0 / 0
03.10.2008, 11:09
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574210
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
Belyлибо пользователь хотел видеть не то, что программа считала
нужным.
Так ты и консультируйся с особой, компетентной в данной области или - век
живи, век учись.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
03.10.2008, 11:18
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574231
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Valentin Kotelnitski
Belyлибо пользователь хотел видеть не то, что программа считала
нужным.
Так ты и консультируйся с особой, компетентной в данной области или - век
живи, век учись.А я и не собираюсь писать супер программу, которая сама знает что показывать.
...
Рейтинг: 0 / 0
03.10.2008, 11:22
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574266
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
2Bely
Мне почему-то показалось, что ты считал, что для того чтобы узнать, что же
пользователю нужно, совсем не обязательно его понимать. Типа я волхв.
Я как раз и предлагал аналитику поставить себя на место пользователя
и выяснить, что же ему нужно.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
03.10.2008, 11:30
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574317
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
Т.е. считал что я считаю что...
Я прочел ПОНЯТЬ - признаю, что я тормоз :-)
Перефразируя, я предлагал "влезть в шкуру" компетентного пользователя.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
03.10.2008, 11:45
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574353
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
В смысле сначала обратил внимание на то, что ты настроен скептически, а
только потом прочел ПОНЯТЬ.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
03.10.2008, 11:53
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35574372
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
И вспоминая наши предыдущие баталии...

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
03.10.2008, 11:59
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35575514
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Только сходил ребенку молока купить, а здесь уже баталии начались:))
Чайк у , и отвечу подробно.
...
Рейтинг: 0 / 0
03.10.2008, 17:01
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35575543
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Valentin Kotelnitski
Надо хорошо подумать, какой набор полей нужен пользователю и написать
запрос.


Так ведь необходимые поля в справочниках и оперативных таблицах и заказаны самим пользователем.
Теперь, важное! Мне будет очень трудно объяснить пользователю, почему просматривая справочник заказчиков он может видеть поля Наименование, Адрес, Тип хоз. деятельности , а просматривая таблицу заказов он может видеть только Наименование и Адрес . Понятно, что есть более важные поля и есть менее. Так вот, более важные поля будут отмечены для показа по умолчанию, но все остальные также будут доступны.
Производительность(быстродействие) в данном конкретном случае меня практически не интересует, также, как и огранияения, связанные с памятью.
...
Рейтинг: 0 / 0
03.10.2008, 17:16
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35575567
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaТак ведь необходимые поля в справочниках и оперативных таблицах и заказаны самим пользователем.
Теперь, важное! Мне будет очень трудно объяснить пользователю, почему просматривая справочник заказчиков он может видеть поля Наименование, Адрес, Тип хоз. деятельности , а просматривая таблицу заказов он может видеть только Наименование и Адрес . Понятно, что есть более важные поля и есть менее. Так вот, более важные поля будут отмечены для показа по умолчанию, но все остальные также будут доступны.
Производительность(быстродействие) в данном конкретном случае меня практически не интересует, также, как и огранияения, связанные с памятью.Ну если пользователь хочет - то это одно.
Но обычно выдача всей информации в одной таблице сводится к простыне из 30-40 полей, с которой потом нельзя нормально работать.

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

Зато, используя SQL вы можете выдавать данные гораздо красивее, лучше и больше, чем сможет выдавать такой инструмент.
Могу привести примеры запросов, которые врядли сможет сгенерить автомат.
...
Рейтинг: 0 / 0
03.10.2008, 17:26
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35575601
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Bely
Ну что сказать...
Все мне известные попытки написания таких программ - ни к чему хорошему не привели.

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

Самое трудное в программировании - это не составить запрос (или 10 запросов), а ПОНЯТЬ что надо показать пользователю. Написать запрос с JOIN-ами для всех таблиц - ну максимум пару дней. А вот понять что именно надо пользователю для ЭФФЕКТИВНОЙ работы - тут приходится голову ломать всем.

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

Проблема именно в том, что мне трудно писать, а затем сопровождать кучу отдельных запросов. Ну не выношу я черной работы... Я хочу (хотеть я имею право?!), чтобы запросы генерировались програмно, автоматически, благо есть чистая (классически построенная БД).
P.S. Возможно, мне и потребуется писать специфические запросы для каких-то хитрых желаний пользователя, но это будет либо отдельная программа, либо отдельный модуль отчентов. Пока мне не хотелось бы думать ни о первом, ни о втором. Сейчас речь идет лишь о Create, read, update and delete ( CRUD ) приложении, работающем день ото дня в скучном, стандартном режиме, а не пульте управления полетами, где требуется то химсостав батареи проанализировать, то орбиту подправить :)
...
Рейтинг: 0 / 0
03.10.2008, 17:39
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35575654
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Bely
Но обычно выдача всей информации в одной таблице сводится к простыне из 30-40 полей, с которой потом нельзя нормально работать.

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

Bely
Что касается инструмента, который будет создавать SQL запросы - время потраченное на составление схемы данных для такого инструмента будет сопоставимо со временем потраченным на написание самих SQL запросов.
Оно вам надо - делать то же самое, но через задний проход?

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

Во-первых. Нашелся человек, который сказал: Слушай, мне нравится твоя программа, как средство ввода и изменения даннных CRUD, но твои жалкие потуги сделать нормальную систему отчетов не идут ни в какое сравнение с нашими репорт-генераторами, графо-построителями, эвристическими анализаторами данных и прочими уважаемыми инструментами, для которых у нас есть все - лицензии, специалисты, время. Твои репорты нам по барабану, дай нам доступ к твоей БД и мы сами получим всё, что нам нужно и в том виде, в котором это необходимо.
- Ага, приехали, подумал я... База данных-то с хитрецой... Я имею ввиду этот длинный VARCHAR , в котором были собраны все поля.
Весь мощный инструментарий того дяди вмиг встал и все спецы развели руками и ушли пить пиво. И правильно сделали.
В нашем мире нужно быть максимально переносимым и совместимым, чтобы уметь договариваться и сотрудничать с другими людьми.

Во-вторых , через какое-то время после написания этой "чудо-программы", я попытался переосмыслить, как она работает. И не смог. Сложно, длинно и непонятно. Т.е. сам-же не смог разобраться со своими-же исходниками. Разозлился я (думаю, понятно на кого:-), сжег все рукописи и на какое-то время отошел от дел.
...
Рейтинг: 0 / 0
03.10.2008, 18:12
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35576035
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Кажется, я пишу генератор...
Мне хотелось бы услышать вашу критику. Может быть действительно, зря все?...

ЦЕЛЬ:

Единый механизм построения SELECT/INSERT/UPDATE/DELETE для всех таблиц.

ТРУДНОСТИ РЕАЛИЗАЦИИ:

1. Необходима генерация алиасов, для каждого из полей объединения.
2. Необходимо каким-то образом из имени алиаса получить имя исходной таблицы и поля (парсинг алиаса)
3. Необходимо отсортировать список таблиц в порядке увеличеня ссылок на них. Самые простые таблицы - это те, у которых вообще нет связи с другими, таким таблицам место вверху. Далее идут таблицы, которые связаны со справочниками, которые сами по себе не связаны с другими таблицами, и т.д. На данном этапе мне не совсем понятно, как это сделать, поэтому, для начала, я скормлю генератору уже отсортированный вручную список таблиц.

ИСХОДНЫЕ ПОСЫЛКИ:

1. PRIMARY KEY - суррогатный ключ
2. Название поля для PRIMARY KEY - ID
3. Название поля для FOREIGN KEY - {внешняя_таблица__ID} Например: CUSTOMERS__ID


СТРАТЕГИЯ:

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


РЕАЛИЗАЦИЯ:

Схема действий, которую язык не поворачивается назвать алгоритмом примерно следующая.
1. Анализируем описание таблицы.
2 Если нет ссылок на справочники, пропускаем, потому что во VIEW в этом случае просто нет необходимости.
3. Если есть ссылки на справочники, строим VIEW с соответствующими LEFT OUTER JOIN-ами.
4 Переходим к следующей таблице.


P.S. Возможно, даже скорее всего, я изложил идеи не очень ясно. На этом этапе у меня самого еще нет полного понимания.
...
Рейтинг: 0 / 0
04.10.2008, 00:55
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35576598
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
korda2. Необходимо каким-то образом из имени алиаса получить имя исходной таблицы и поля (парсинг алиаса)А зачем?
Запрос строит программа, а значит результатом ее работы может стать не только текст запроса, но и таблица соответствия полей и алиасов.

korda3. Название поля для FOREIGN KEY - {внешняя_таблица__ID} Например: CUSTOMERS__IDполе можно называть как угодно, если для построения FK использовать системные таблицы. В них можно натий по каким полям связаны таблицы. Иначе непонятно как быть с несколькими полями в одной таблице, которые будут ссылаться на другую таблицу.
Например: в таблице организации будет три поля ссылки на таблицу адресов: адрес фактический, адрес почтовый, адрес юридический.

korda3. Необходимо отсортировать список таблиц в порядке увеличеня ссылок на них. Самые простые таблицы - это те, у которых вообще нет связи с другими, таким таблицам место вверху. Далее идут таблицы, которые связаны со справочниками, которые сами по себе не связаны с другими таблицами, и т.д. На данном этапе мне не совсем понятно, как это сделать, поэтому, для начала, я скормлю генератору уже отсортированный вручную список таблиц.1) Как отличить таблицы справочники от основных таблиц?
2) Что делать со связью "много-ко-многим". Возьмем вырожденный случай, когда у нас в базе 3 таблицы. Таблица "Люди", таблица "Адреса" и таблица связи между ними. следуя вашей логике основной таблицей становится таблица связи, а таблицы "Люди" и "Адреса" - становятся справочниками.
3) Самый непонятный вопрос - какие названия полей показывать пользователю? Не будем же мы пользователю показывать MAIN_POST_ADDRESS_ID вместо "Основной почтовый адрес". Взять названия полей неоткуда.
4) как разбираться со ссылками на самого себя?
5) Как различить случаи MASTER DETAIL от ссылки на другой объект?
MASTER DETAIL:
таблица "Организации" (ID, NAME)
таблица "Телефоны" (ID, ORG_ID, PHONE )

Ссылка на объект:
таблица "Организации" (ID, NAME, PHONE_ID)
таблица "Телефоны" (ID, PHONE)

То что вы пытаетесь сделать - это восстановление ЛОГИЧЕСКОЙ структуры базы по ФИЗИЧЕСКОЙ. А эта задача неразрешима.

Для описания логической структуры базы при имеющиейся физической - используют метаданные.
т.е. специальное описание объектов БД, связей между ними и т.п.
Далее пользовательский интерфейс, запросы, гриды - строят уже ПО МЕТАДАННЫМ, а не по физической модели.
Но метаданные - надо будет все ввести вручную.
...
Рейтинг: 0 / 0
05.10.2008, 10:42
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35577004
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Bely , спасибо за ценные (действительно ценные) замечания!
Bely korda2. Необходимо каким-то образом из имени алиаса получить имя исходной таблицы и поля (парсинг алиаса)
А зачем?
Запрос строит программа, а значит результатом ее работы может стать не только текст запроса, но и таблица соответствия полей и алиасов.

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

Bely korda3. Название поля для FOREIGN KEY - {внешняя_таблица__ID} Например: CUSTOMERS__IDполе можно называть как угодно, если для построения FK использовать системные таблицы. В них можно натий по каким полям связаны таблицы. Иначе непонятно как быть с несколькими полями в одной таблице, которые будут ссылаться на другую таблицу.
Например: в таблице организации будет три поля ссылки на таблицу адресов: адрес фактический, адрес почтовый, адрес юридический.


Спасибо, за ценное замечание! Этот аспект я совершенно упустил из вида. Видимо имя FOREIGN KEY должно содержать ещё и поряковый номер связи. Что-то вроде: CUSTOMERS__2ID.

BelyКак отличить таблицы справочники от основных таблиц?


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

Bely
3) Самый непонятный вопрос - какие названия полей показывать пользователю? Не будем же мы пользователю показывать MAIN_POST_ADDRESS_ID вместо "Основной почтовый адрес". Взять названия полей неоткуда.


Представьте, я тоже думал на эту тему! Вот что я предполагаю сделать.
Приложение в целом имеет свои текстовые файлы единого типа для поддержки ВСЕХ имеющихся в нем строк на различных языках, например:

Код: plaintext
1.
2.
3.
00234=Вы действительно желаете удалить %s принтеров? в файле messages_ru.txt
00234=Are you sure, you want to delete %s printers? в файле messages_en.txt
00234=ウェブ、画像、動画、ブログ検索 %s を提供する、百度? в файле messages_ja.txt
и т.д.

В описании поля нужно будет отвести параметр для ссылки на файл messages_XX.txt
что-то типа того:
Код: plaintext
<column type="VARCHAR" message_id="1234">MAIN_POST_ADDRESS</column>

P.S. Кстати, в документации по поводу column label, он же алиас, написано:
Gets the designated column's suggested title for use in printouts and displays.
 Однако, column label поддерживает только ASCII - это раз и как быть со всякими там пробелами и прочим в именах алиасов не ясно - это два. Ну и одновременная поддержка различных языков тоже не понятно как может быть выполнена - это три.

Bely
как разбираться со ссылками на самого себя?

Отличный вопрос, который я тоже упустил из вида!
Может быть имя VIEW и алиас должны содержать порядковый номер ссылки?
view: WORKERS_12, алиас поля: WORKERS_12_AGE

Bely
5) Как различить случаи MASTER DETAIL от ссылки на другой объект?
MASTER DETAIL:
таблица "Организации" (ID, NAME)
таблица "Телефоны" (ID, ORG_ID, PHONE )

Ссылка на объект:
таблица "Организации" (ID, NAME, PHONE_ID)
таблица "Телефоны" (ID, PHONE)

Я хочу уйти от представления документов на экране в виде шапка(header), а под ней строки(details).
(Если будет интересно, расскажу почему). Если пользователь просматривает справочник организаций, а у каждой из организаций есть список телефонов отделов, то это не значит, что вверху я напишу НОВОПРЕСНЕСКИЙ СТРОИТЕЛЬНО-МОНТАЖНЫЙ КОМБИНАТ, а внизу будет таблица с телефонами. Вместо этого, пользователь кликнет на какую-то там кнопку и ему покажется полнофункциональный справочник телефонов, но в котором доступны лишь телефоны просматриваемой организации, с соответствующими Добавить/Изменить/Удалить.
...
Рейтинг: 0 / 0
05.10.2008, 21:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35577048
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
С учетом замечаний Bely (1. Ссылка таблицы на саму себя, 2. Несколько ссылок на один и тот-же справочник) похоже, что основная сложность такого генератора - это построение таблицы соответствия поле - алиас .

Имя такую таблицу можно не заботиться более об именах алиасов, а генерировать их с помощью сквозной нумерации ( A1, A2, A3 ... и т.д.)
...
Рейтинг: 0 / 0
05.10.2008, 23:00
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35577122
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Об отображаемых пользователю текстах(именах) полей.

Анализирую ситуацию с текстом полей и прихожу к выводу, что текст поля, в случае развернутого запроса (таблица, с прилинкованными полями справочников) не может быть задан в описании поля при создании таблицы. Так, если таблица Заказы имеет несколько связей со справочником Адреса, то нужно каким-то образом указать, что это поле - суть адрес клиента, а то - адрес исполнителя. Получается, что для каждого поля объединения нужен свой уникальный, рукотворный текст типа "Адрес клиента" и "Адрес исполнителя"
...
Рейтинг: 0 / 0
06.10.2008, 00:50
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35577870
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
Bely korda2. Необходимо каким-то образом из имени алиаса получить имя исходной таблицы и поля (парсинг алиаса)А зачем?
Запрос строит программа, а значит результатом ее работы может стать не только текст запроса, но и таблица соответствия полей и алиасов.

korda3. Название поля для FOREIGN KEY - {внешняя_таблица__ID} Например: CUSTOMERS__IDполе можно называть как угодно, если для построения FK использовать системные таблицы. В них можно натий по каким полям связаны таблицы. Иначе непонятно как быть с несколькими полями в одной таблице, которые будут ссылаться на другую таблицу.
Например: в таблице организации будет три поля ссылки на таблицу адресов: адрес фактический, адрес почтовый, адрес юридический.

korda3. Необходимо отсортировать список таблиц в порядке увеличеня ссылок на них. Самые простые таблицы - это те, у которых вообще нет связи с другими, таким таблицам место вверху. Далее идут таблицы, которые связаны со справочниками, которые сами по себе не связаны с другими таблицами, и т.д. На данном этапе мне не совсем понятно, как это сделать, поэтому, для начала, я скормлю генератору уже отсортированный вручную список таблиц.1) Как отличить таблицы справочники от основных таблиц?
2) Что делать со связью "много-ко-многим". Возьмем вырожденный случай, когда у нас в базе 3 таблицы. Таблица "Люди", таблица "Адреса" и таблица связи между ними. следуя вашей логике основной таблицей становится таблица связи, а таблицы "Люди" и "Адреса" - становятся справочниками.
3) Самый непонятный вопрос - какие названия полей показывать пользователю? Не будем же мы пользователю показывать MAIN_POST_ADDRESS_ID вместо "Основной почтовый адрес". Взять названия полей неоткуда.
4) как разбираться со ссылками на самого себя?
5) Как различить случаи MASTER DETAIL от ссылки на другой объект?
MASTER DETAIL:
таблица "Организации" (ID, NAME)
таблица "Телефоны" (ID, ORG_ID, PHONE )

Ссылка на объект:
таблица "Организации" (ID, NAME, PHONE_ID)
таблица "Телефоны" (ID, PHONE)

То что вы пытаетесь сделать - это восстановление ЛОГИЧЕСКОЙ структуры базы по ФИЗИЧЕСКОЙ. А эта задача неразрешима.

Для описания логической структуры базы при имеющиейся физической - используют метаданные.
т.е. специальное описание объектов БД, связей между ними и т.п.
Далее пользовательский интерфейс, запросы, гриды - строят уже ПО МЕТАДАННЫМ, а не по физической модели.
Но метаданные - надо будет все ввести вручную.

Да, где-то так и есть.
Вполне решаемая, кстати, задача.
Не бог весть, какая хитрость собрать запрос по хорошему описанию.
...
Рейтинг: 0 / 0
06.10.2008, 12:43
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35577874
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
korda Об отображаемых пользователю текстах(именах) полей.

Анализирую ситуацию с текстом полей и прихожу к выводу, что текст поля, в случае развернутого запроса (таблица, с прилинкованными полями справочников) не может быть задан в описании поля при создании таблицы. Так, если таблица Заказы имеет несколько связей со справочником Адреса, то нужно каким-то образом указать, что это поле - суть адрес клиента, а то - адрес исполнителя. Получается, что для каждого поля объединения нужен свой уникальный, рукотворный текст типа "Адрес клиента" и "Адрес исполнителя"

Отображаемые пользователю названия полей, натурально, нужно хранить в тех же метаданных, в которых описано и все остальное.
...
Рейтинг: 0 / 0
06.10.2008, 12:46
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35577915
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
kordaС учетом замечаний Bely (1. Ссылка таблицы на саму себя, 2. Несколько ссылок на один и тот-же справочник) похоже, что основная сложность такого генератора - это построение таблицы соответствия поле - алиас .

Имя такую таблицу можно не заботиться более об именах алиасов, а генерировать их с помощью сквозной нумерации ( A1, A2, A3 ... и т.д.)

Начните лучше с начала ;).
Представьте, как бы мог выглядеть интефейс настройки такой системы.
- Сначала надо выбрать "главную" таблицу, назначить в ней условия, поля.
- Потом для этой таблицы нужно назначить список "дочерних" таблиц.
Удобнее всего это делать из списка всех возможных связей "главной" таблицы. Это и есть таблица "Ассоциации". В которой, помимо связанных таблиц, указаны и названия связей "на русском языке", что бы было понятно, что и зачем связано. Дополнительно, для каждой ассоциации необходимо указать и способ связи. Это можно сделать, например, через список соответствующих полей из связанных таблиц (в отдельной таблице), либо в виде части SQL выражения, которая подставляется в WHERE. Я сталкивался с обоими способами, оба имеют свои достоинства и недостатки.
- Для каждой "дочерней" таблицы необходимо назначить список ее "еще более дочерних" таблиц. Это делается аналогично.
- Результат такого построения необходимо также сохранить.

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

Правила отображения отобраных данных нужно хранить несколько отдельно от правил отбора (подготовки) этих данных. То есть, должна быть система "источник данных" и система "отображение данных". Не разделите эти системы - не выкопаетесь никогда.
...
Рейтинг: 0 / 0
06.10.2008, 13:00
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35578111
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Николай1
При построении таблицы ассоциаций необходимо помнить о циклических ссылках и предпринимать меры по избежанию зацикливания.

Николай , верно ли, что циклические ссылки - это плохо продуманный дизайн модели данных и без них всегда можно обойтись?
Я не иронизирую, я просто спрашиваю.
...
Рейтинг: 0 / 0
06.10.2008, 14:09
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35578248
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
korda Николай , верно ли, что циклические ссылки - это плохо продуманный дизайн модели данных и без них всегда можно обойтись?
Я не иронизирую, я просто спрашиваю.А как вы собираетесь, например, изображать иерархические справочники? Они ссылаются сами на себя - цикл.
...
Рейтинг: 0 / 0
06.10.2008, 14:46
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35578404
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
korda Николай1
При построении таблицы ассоциаций необходимо помнить о циклических ссылках и предпринимать меры по избежанию зацикливания.

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

Не видел ни одной базы без циклических ссылок.
Например - филиалы и контрагенты. В циклических ссылках нет проблем.
...
Рейтинг: 0 / 0
06.10.2008, 15:40
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35578609
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
BelyА как вы собираетесь, например, изображать иерархические справочники? Они ссылаются сами на себя - цикл.
Опередили :) Наличие иерархических справочников ставит на все затею жирный крест. На самом деле автору нужно подумать о системе навигации по своим данным.
...
Рейтинг: 0 / 0
06.10.2008, 16:47
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579052
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
_мод BelyА как вы собираетесь, например, изображать иерархические справочники? Они ссылаются сами на себя - цикл.
Опередили :) Наличие иерархических справочников ставит на все затею жирный крест. На самом деле автору нужно подумать о системе навигации по своим данным.

Я понял, что циклические ссылки - явление совершенно законное и полезное.
Так что, никакого креста... Просто, нужно учесть это. Алиасы для имен таблиц, разве не для подобных случаев выход? Если таблица ссылается на саму себя, то в одном предложении SQL она будет помечена различными алиасами T1 и T2, например. Или я что-то упускаю из вида?
...
Рейтинг: 0 / 0
06.10.2008, 19:37
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579243
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Начал я анализировать ситуацию с циклическими ссылками...

Например, таблица, в которой одно из полей ссылается на другую запись этой-же таблицы, а та, другая запись в свою очередь может ссылаться ещё на какую нибудь запись, опять-же из этой самой таблицы. И так можно линковать "до бесконечности"...
Получается, что количество полей такого запроса в общем случае неопределено и в каком-то смысле зависит от количества записей в таблице.
Понятно, что такая таблица, растущая по-горизонтали в бесконечность меня не устраивает.
Этот рост можно искусственно ограничить, ограничив уровень "прилинковки" ссылок каким-то определенным значением. И это значение "напрашивается" быть равным единице. (Потому что, если это будет 2, 3 или 33, будет очень трудно объяснить логику по которой оно выбрано).
Я пишу может быть излишне подробно, чтобы избежать разночтений.

Итак, циклические ссылки ограничены первым уровнем. Это означает, что в таблице "Пассажиры самолета" мы имеем две записи: Иван Иванович, у которого дочь Наташа и запись самой дочери Ивана Ивановича т.е. Наташи. Если у Наташи тоже есть свои дети, то они в записи Ивана Ивановича отображаться не будут, а сама Наташа - будет. Здесь присутствует ещё один аспект. В записи Наташи будут ссылки на различные справочники, так вот, эти ссылки тоже не будут отображаться при выдачи записи Ивана Ивановича. Т.е. об Иване Ивановиче будет выдаваться вся имеющаяся информация, включая то, что у него есть дочь Наташа, но вот, чтобы посмотреть справочные данные этой самой Наташи нужно будет нажать кнопку в GUI, которая и перенесет нас в "мир Наташи".
...
Рейтинг: 0 / 0
06.10.2008, 23:04
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579416
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
kordaНачал я анализировать ситуацию с циклическими ссылками...

Например, таблица, в которой одно из полей ссылается на другую запись этой-же таблицы, а та, другая запись в свою очередь может ссылаться ещё на какую нибудь запись, опять-же из этой самой таблицы. И так можно линковать "до бесконечности"...
Получается, что количество полей такого запроса в общем случае неопределено и в каком-то смысле зависит от количества записей в таблице.
Понятно, что такая таблица, растущая по-горизонтали в бесконечность меня не устраивает.
Этот рост можно искусственно ограничить, ограничив уровень "прилинковки" ссылок каким-то определенным значением. И это значение "напрашивается" быть равным единице. (Потому что, если это будет 2, 3 или 33, будет очень трудно объяснить логику по которой оно выбрано).
Я пишу может быть излишне подробно, чтобы избежать разночтений.

Итак, циклические ссылки ограничены первым уровнем. Это означает, что в таблице "Пассажиры самолета" мы имеем две записи: Иван Иванович, у которого дочь Наташа и запись самой дочери Ивана Ивановича т.е. Наташи. Если у Наташи тоже есть свои дети, то они в записи Ивана Ивановича отображаться не будут, а сама Наташа - будет. Здесь присутствует ещё один аспект. В записи Наташи будут ссылки на различные справочники, так вот, эти ссылки тоже не будут отображаться при выдачи записи Ивана Ивановича. Т.е. об Иване Ивановиче будет выдаваться вся имеющаяся информация, включая то, что у него есть дочь Наташа, но вот, чтобы посмотреть справочные данные этой самой Наташи нужно будет нажать кнопку в GUI, которая и перенесет нас в "мир Наташи".Ура!
...
Рейтинг: 0 / 0
07.10.2008, 08:29
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579566
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
Это теоретически. А практически, чтобы что-то написать, самолет должен быть
приземлен. Неконкретно все это.
Почему бы не написать набор своих ручных запросов, как я предлагал?

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.10.2008, 09:59
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579663
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaНапример, таблица, в которой одно из полей ссылается на другую запись этой-же таблицы, а та, другая запись в свою очередь может ссылаться ещё на какую нибудь запись, опять-же из этой самой таблицы. И так можно линковать "до бесконечности"...
Получается, что количество полей такого запроса в общем случае неопределено и в каком-то смысле зависит от количества записей в таблице.
 Для этого придумали иерархические запросы. Например такой (Oracle).
Код: plaintext
1.
2.
3.
4.
5.
SELECT c.id, c.parent_id, c.name, c.is_active
  , sys_connect_by_path(c.name,'/') as path
FROM act_clf c
WHERE c.is_active =  1 
START WITH c.parent_id =  1 
CONNECT BY prior c.id = c.parent_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.
ID                                   	PARENT_ID                                     	NAME                                                                         	PATH
810                                   	1                                     	Связь и ИТ                                                                         	/Связь и ИТ
811                                   	810                                   	Ведомственные и корпоративные информационные системы и сети связи                  	/Связь и ИТ/Ведомственные и корпоративные информационные системы и сети связи
812                                   	811                                   	Филиалы, департаменты, отделы ИТ                                                   	/Связь и ИТ/Ведомственные и корпоративные информационные системы и сети связи/Филиалы, департаменты, отделы ИТ
813                                   	811                                   	Отраслевые предприятия информационных систем и сетей связи                         	/Связь и ИТ/Ведомственные и корпоративные информационные системы и сети связи/Отраслевые предприятия информационных систем и сетей связи
814                                   	810                                   	Операторы сетей связи и интернет                                                   	/Связь и ИТ/Операторы сетей связи и интернет
816                                   	814                                   	Операторы фиксированной телефонной связи                                           	/Связь и ИТ/Операторы сетей связи и интернет/Операторы фиксированной телефонной связи
817                                   	814                                   	Операторы сотовой связи                                                            	/Связь и ИТ/Операторы сетей связи и интернет/Операторы сотовой связи
818                                   	814                                   	Интернет провайдеры, Хостинг провайдеры                                            	/Связь и ИТ/Операторы сетей связи и интернет/Интернет провайдеры, Хостинг провайдеры
819                                   	814                                   	Операторы IP-телефонии                                                             	/Связь и ИТ/Операторы сетей связи и интернет/Операторы IP-телефонии
820                                   	814                                   	Call-центры и операторы пейджинговой связи                                         	/Связь и ИТ/Операторы сетей связи и интернет/Call-центры и операторы пейджинговой связи
821                                   	814                                   	Прочее                                                                             	/Связь и ИТ/Операторы сетей связи и интернет/Прочее
890                                   	814                                   	Общее                                                                              	/Связь и ИТ/Операторы сетей связи и интернет/Общее
815                                   	810                                   	Группы компаний и холдинги операторов связи                                        	/Связь и ИТ/Группы компаний и холдинги операторов связи
822                                   	810                                   	Разработка программного обеспечения, АСУ (автоматизированные системы управления)   	/Связь и ИТ/Разработка программного обеспечения, АСУ (автоматизированные системы управления)
823                                   	810                                   	Интеграторы, монтажные и сервисные организации                                     	/Связь и ИТ/Интеграторы, монтажные и сервисные организации
824                                   	823                                   	Системные интеграторы                                                              	/Связь и ИТ/Интеграторы, монтажные и сервисные организации/Системные интеграторы
825                                   	823                                   	Строительно-монтажные организации                                                  	/Связь и ИТ/Интеграторы, монтажные и сервисные организации/Строительно-монтажные организации
826                                   	823                                   	Сервисные организации                                                              	/Связь и ИТ/Интеграторы, монтажные и сервисные организации/Сервисные организации
915                                   	823                                   	Общее                                                                              	/Связь и ИТ/Интеграторы, монтажные и сервисные организации/Общее
827                                   	810                                   	Общее                                                                              	/Связь и ИТ/Общее
100                                   	1                                     	Производство, промышленность                                                       	/Производство, промышленность
792                                   	100                                   	Общее                                                                              	/Производство, промышленность/Общее
828                                   	100                                   	Металлургический комплекс                                                          	/Производство, промышленность/Металлургический комплекс
829                                   	828                                   	Холдинги металлургического комплекса                                               	/Производство, промышленность/Металлургический комплекс/Холдинги металлургического комплекса
830                                   	828                                   	Черная металлургия                                                                 	/Производство, промышленность/Металлургический комплекс/Черная металлургия
831                                   	830                                   	Металлургические комбинаты и заводы                                                	/Производство, промышленность/Металлургический комплекс/Черная металлургия/Металлургические комбинаты и заводы
832                                   	830                                   	Горно-обогатительные комбинаты (ГОК) и горно-рудные предприятия черной металлургии 	/Производство, промышленность/Металлургический комплекс/Черная металлургия/Горно-обогатительные комбинаты (ГОК) и горно-рудные предприятия черной металлургии
...
Рейтинг: 0 / 0
07.10.2008, 10:35
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579717
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
kordaно вот, чтобы посмотреть справочные данные этой самой Наташи нужно будет нажать кнопку в GUI, которая и перенесет нас в "мир Наташи".
Вот так и должна быть построена вся система навигации без всяких безразмерных таблиц.
...
Рейтинг: 0 / 0
07.10.2008, 10:55
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579748
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
мод!
Может, мы еще, кроме навигации, разберем и систему управления полетами?
Вернемся к нашим баранам. Почему мы абстрагируемся когда пишем нечто
конкретное?

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.10.2008, 11:07
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579756
sti
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sti
Участник
kordaНачал я анализировать ситуацию с циклическими ссылками...
Вот только я не понял, Наташа то тоже в том же самолете сидит или неважно это автору?
...
Рейтинг: 0 / 0
07.10.2008, 11:11
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579823
_mashuta_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_mashuta_
Участник
Может быть, Вам нужен Hibernate? Он умеет строить SQL-запросы...
...
Рейтинг: 0 / 0
07.10.2008, 11:32
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579868
Неизвестный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Неизвестный
Гость
kordaПисать самому такую программу мне страшно. Или мне лишь кажется, что это не просто?

Начинать такую программу лучше после обеда, когда обычно бывает хорошее настроение, тогда как раз к завершению рабочего дня завершите эту программу. Чем страшнее начинать - тем приятнее кончать.
...
Рейтинг: 0 / 0
07.10.2008, 11:45
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35579922
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
Неизветный -
Пустое. Задача крайне непростая...

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.10.2008, 12:02
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35580506
Lenivec
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lenivec
Участник
задача состоит в разрезании n-мерного куба на x двухмерных срезов
построить все возможные срезы для существующей модели базы данных возможно, но имеет ли смысл?

в своем проекте я реализовывал три вида ведомостей: бухгалтерские, тмц, основных средств
все они предполагают неограниченную вложенность аналитики, тоесть фактически n-мерный куб
задача получается сходная, справочников может быть каких угодно и сколько угодно, неограниченное количество и все они могут быть тем или иным образом прицеплены к базовой операции (проводке, движению тмц, движению ос)

так вот, фактически определенный набор статических срезов я строю всегда, а остальной неограниченный набор срезов строятся только по запросу, тоесть пользователь должен указать какие срезы он хочет увидеть в результирующей выборке
...
Рейтинг: 0 / 0
07.10.2008, 14:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35580686
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
2Lenivec
Он тебя вообще поймет? А если поймет, то хватит ли ему в реале квалификации?

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
07.10.2008, 15:25
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35580827
474
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
474
Участник
Valentin Kotelnitski
2Lenivec
Он тебя вообще поймет? А если поймет, то хватит ли ему в реале квалификации?
Вам корона не жмет?
...
Рейтинг: 0 / 0
07.10.2008, 15:58
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581163
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
Lenivecзадача состоит в разрезании n-мерного куба на x двухмерных срезов
построить все возможные срезы для существующей модели базы данных возможно, но имеет ли смысл?

в своем проекте я реализовывал три вида ведомостей: бухгалтерские, тмц, основных средств
все они предполагают неограниченную вложенность аналитики, тоесть фактически n-мерный куб
задача получается сходная, справочников может быть каких угодно и сколько угодно, неограниченное количество и все они могут быть тем или иным образом прицеплены к базовой операции (проводке, движению тмц, движению ос)

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

Ну, типа того.
...
Рейтинг: 0 / 0
07.10.2008, 17:13
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581264
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
Valentin KotelnitskiПочему мы абстрагируемся когда пишем нечто конкретное?

Абстракция - лучший способ достичь конкретных результатов :) Автору как раз ее и недостает
...
Рейтинг: 0 / 0
07.10.2008, 17:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581664
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Valentin Kotelnitski
Почему бы не написать набор своих ручных запросов, как я предлагал?


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

Bely
Для этого придумали иерархические запросы. Например такой (Oracle).


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

_мод kordaно вот, чтобы посмотреть справочные данные этой самой Наташи нужно будет нажать кнопку в GUI, которая и перенесет нас в "мир Наташи".
Вот так и должна быть построена вся система навигации без всяких безразмерных таблиц.

Т.е. не прилинковывать данные справочников вообще?... Это ведь не то, что Вы хотели сказать, правда?
А если прилинковывать (связывать таблицу со справочниками), то почему-бы не делать это программно?

_mashuta_Может быть, Вам нужен Hibernate? Он умеет строить SQL-запросы...
Может быть... Но вся сложность, в данном случае, не в построении запросов, а в их автоматической генерации.

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


В данном случае нет необходимости в построении всех возможных срезов, пусть этим занимаются специализированные инструменты. Запросы нужны для банальной программы ввода и модификации данных. Все возможные связи между таблицами жестко определены и неизменяются в процессе работы программы.
...
Рейтинг: 0 / 0
07.10.2008, 20:51
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581691
Lenivec
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lenivec
Участник
2 korda

либо вы сами себе противоречите, либо сами же не можете понять что конкретно хотите получить
...
Рейтинг: 0 / 0
07.10.2008, 21:31
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581783
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Lenivec2 korda

либо вы сами себе противоречите, либо сами же не можете понять что конкретно хотите получить

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

1. Имеется описание таблиц и связей между ними.
1.1 Во всех таблицах PRIMARY KEY - суррогатные, одного типа, генерируемые одним и тем-же методом.
1.2 Во всех таблицах PRIMARY KEY имеют одинаковое имя - ID.

2. Задано, какие поля и из каких таблиц должны присутствовать в запросе:
2.1 Все поля, всех связанных с таблицей справочника.
2.2 Если имеются циклические связи, то они ограничиваются первым уровнем.

3. Программа должна получить описание таблиц и связей между ними и сгенерировать предложения для требуемых SELECT -ов.
...
Рейтинг: 0 / 0
07.10.2008, 22:47
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581802
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Произведение "искусственного интеллекта", в том виде, в каком у него это выходит на сегодняшний вечер.
(Извиняюсь, за полную нечитабельность данного опуса)

Код: 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 A_0__V_PERSON__ID
,T0.TIME_S AS A_1__V_PERSON__TIME_S
,T0.TIME_E AS A_2__V_PERSON__TIME_E
,T0.USER AS A_3__V_PERSON__USER
,T0.NAME AS A_4__V_PERSON__NAME
,T0.AGE AS A_5__V_PERSON__AGE
,T0.WORKPLACE1_ID AS A_6__V_PERSON__WORKPLACE1_ID
,T0.WORKPLACE2_ID AS A_7__V_PERSON__WORKPLACE2_ID
,T0.WORKPLACE2_TWO_ID AS A_8__V_PERSON__WORKPLACE2_TWO_ID
,T0.OTHER_PERSON_ID AS A_9__V_PERSON__OTHER_PERSON_ID
,T1.ID AS A_10__W_WORKPLACE1__ID
,T1.TIME_S AS A_11__W_WORKPLACE1__TIME_S
,T1.TIME_E AS A_12__W_WORKPLACE1__TIME_E
,T1.USER AS A_13__W_WORKPLACE1__USER
,T1.TYPE AS A_14__W_WORKPLACE1__TYPE
,T2.A_0__V_WORKPLACE2__ID AS A_15__W_WORKPLACE2__A_0__V_WORKPLACE2__ID
,T2.A_1__V_WORKPLACE2__TIME_S AS A_16__W_WORKPLACE2__A_1__V_WORKPLACE2__TIME_S
,T2.A_2__V_WORKPLACE2__TIME_E AS A_17__W_WORKPLACE2__A_2__V_WORKPLACE2__TIME_E
,T2.A_3__V_WORKPLACE2__USER AS A_18__W_WORKPLACE2__A_3__V_WORKPLACE2__USER
,T2.A_4__V_WORKPLACE2__TYPE AS A_19__W_WORKPLACE2__A_4__V_WORKPLACE2__TYPE
,T2.A_5__V_WORKPLACE2__ZAVAL_ID AS A_20__W_WORKPLACE2__A_5__V_WORKPLACE2__ZAVAL_ID
,T2.A_6__W_ZAVAL__ID AS A_21__W_WORKPLACE2__A_6__W_ZAVAL__ID
,T2.A_7__W_ZAVAL__TIME_S AS A_22__W_WORKPLACE2__A_7__W_ZAVAL__TIME_S
,T2.A_8__W_ZAVAL__TIME_E AS A_23__W_WORKPLACE2__A_8__W_ZAVAL__TIME_E
,T2.A_9__W_ZAVAL__USER AS A_24__W_WORKPLACE2__A_9__W_ZAVAL__USER
,T2.A_10__W_ZAVAL__SIZE AS A_25__W_WORKPLACE2__A_10__W_ZAVAL__SIZE
,T3.A_0__V_WORKPLACE2__ID AS A_26__W_WORKPLACE2__A_0__V_WORKPLACE2__ID
,T3.A_1__V_WORKPLACE2__TIME_S AS A_27__W_WORKPLACE2__A_1__V_WORKPLACE2__TIME_S
,T3.A_2__V_WORKPLACE2__TIME_E AS A_28__W_WORKPLACE2__A_2__V_WORKPLACE2__TIME_E
,T3.A_3__V_WORKPLACE2__USER AS A_29__W_WORKPLACE2__A_3__V_WORKPLACE2__USER
,T3.A_4__V_WORKPLACE2__TYPE AS A_30__W_WORKPLACE2__A_4__V_WORKPLACE2__TYPE
,T3.A_5__V_WORKPLACE2__ZAVAL_ID AS A_31__W_WORKPLACE2__A_5__V_WORKPLACE2__ZAVAL_ID
,T3.A_6__W_ZAVAL__ID AS A_32__W_WORKPLACE2__A_6__W_ZAVAL__ID
,T3.A_7__W_ZAVAL__TIME_S AS A_33__W_WORKPLACE2__A_7__W_ZAVAL__TIME_S
,T3.A_8__W_ZAVAL__TIME_E AS A_34__W_WORKPLACE2__A_8__W_ZAVAL__TIME_E
,T3.A_9__W_ZAVAL__USER AS A_35__W_WORKPLACE2__A_9__W_ZAVAL__USER
,T3.A_10__W_ZAVAL__SIZE AS A_36__W_WORKPLACE2__A_10__W_ZAVAL__SIZE
,T4.ID AS A_37__V_PERSON__ID
,T4.TIME_S AS A_38__V_PERSON__TIME_S
,T4.TIME_E AS A_39__V_PERSON__TIME_E
,T4.USER AS A_40__V_PERSON__USER
,T4.NAME AS A_41__V_PERSON__NAME
,T4.AGE AS A_42__V_PERSON__AGE
,T4.WORKPLACE1_ID AS A_43__V_PERSON__WORKPLACE1_ID
,T4.WORKPLACE2_ID AS A_44__V_PERSON__WORKPLACE2_ID
,T4.WORKPLACE2_TWO_ID AS A_45__V_PERSON__WORKPLACE2_TWO_ID
,T4.OTHER_PERSON_ID AS A_46__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.A_0__V_WORKPLACE2__ID=T0.WORKPLACE2_ID)
 LEFT JOIN W_WORKPLACE2 AS T3 ON (T3.A_0__V_WORKPLACE2__ID=T0.WORKPLACE2_TWO_ID)
 LEFT JOIN V_PERSON AS T4 ON (T4.ID=T0.OTHER_PERSON_ID)

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

P. S. Может быть есть ещё ситуации, которые я не учел?
...
Рейтинг: 0 / 0
07.10.2008, 23:08
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581918
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Об именах полей.

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

Существует ещё одна, перекликающаяся с именами полей, проблема, которая уже обсуждалась в этой теме. Это отображаемые для конечного пользователя имена полей такого объединения. Ниже приведена выдержка из сообщения, посвященного именам полей:

korda Об отображаемых пользователю текстах(именах) полей.

Анализирую ситуацию с текстом полей и прихожу к выводу, что текст поля, в случае развернутого запроса (таблица, с прилинкованными полями справочников) не может быть задан в описании поля при создании таблицы. Так, если таблица Заказы имеет несколько связей со справочником Адреса, то нужно каким-то образом указать, что это поле - суть адрес клиента, а то - адрес исполнителя. Получается, что для каждого поля объединения нужен свой уникальный, рукотворный текст типа "Адрес клиента" и "Адрес исполнителя"

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

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

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

Таким образом имена полей не будут представлять собой (как это имеет место быть в приведенном выше примере) генерируемые строки, а будут частью метаданных, которые будут поставляться генератору. Естественно, в этом случае возникает проблема уникальности алиаса. Нужно будет "вручную" следить, чтобы алиасы не "перекрывали" друг друга при генерации результирующего запроса, что не есть хорошо. Может быть у кого-нибудь есть идея лучше?
...
Рейтинг: 0 / 0
08.10.2008, 02:06
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35581971
Фотография Valentin Kotelnitski
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valentin Kotelnitski
Участник
kordaМоя цель как раз состоит в отказе от "ручных" запросов.
- Писать такие запросы скучно
- Каждый такой запрос нужно отлаживать и проверять отдельно
- Каждый такой запрос нужно поддерживать при добавлении/удалении полей из соответствующих таблиц.
Каждый такой запрос похож на предыдущий, и поэтому написание его представляет собой рутину, так почему бы не автоматизировать этот процесс?
Это понятно, что лень двигает прогресс...

kordaПроизведение "искусственного интеллекта", в том виде, в каком у него это выходит на сегодняшний вечер.
(Извиняюсь, за полную нечитабельность данного опуса)
Вот именно, это совершенно нечитаемо...
...
Рейтинг: 0 / 0
08.10.2008, 07:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #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
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585636
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher
>>> Пользователь сможет, свободно скрывать, добавлять, менять местами поля, в том числе, разумеется, и те, которые, которые выбраны разработчиком, как поля по умолчанию. Эти манипуляции с полями происходят на уровне GUI, а из таблиц "тянется" всё.

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


Когда я писал ВСЕ, я имел ввиду: все, доступные для пользовательского выбора. GUI я вижу, как таблицу с возможностью сортировки, группировки, поиска и фильтрации. Фотография в такой таблице, находится не обязана. Можно нажать кнопку в GUI и увидеть фото. Но такой подход тоже не однозначен. Представьте таблицу, под которой находится форма с подробностями для каждой записи, вот там и может быть фотография. Пользователь скроллирует записи, а внизу меняются фотографии. При таком подходе фотографию нужно "тянуть" всегда.
...
Рейтинг: 0 / 0
09.10.2008, 14:09
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585658
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
kordaСейчас, какждое физическое поле представляется каким-то образом в системе метаданных. Когда я думал над этой системой, я не учел то, что указатели на описания полей могут быть использованы в выражениях.

Нам не нужно описывать выражения вычисляемых полей в виде ссылок на поля. Достаточно сохранить сам текст 'MAN_ADDR', 'CITY.NAME || STREET.NAME || MAN.APART_NUM' и 'MAN_ADDR', и в нужный момент впихнуть его в SQL-выражение. А что там за текст - SQL разберется. В крайнем случае ошибку выкинет, отладите.

Что это за система метаданных? Какие-то скрипты с особым синтаксисом, программный код с какими-то объектами, служебные таблицы? Почему тривиальное условие стало камнем преткновения?

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

objSQLGen = TSQLGenerator.Create();

objSQLGen.TableName = 'MAN';
objSQLGen.CalcFields.Add('MAN_ADDR', 'CITY.NAME || STREET.NAME || MAN.APART_NUM');

sqlText := objSQLGen.Generate();

Для метаданных в виде таблиц - добавить для таблицы "выборки" связанную таблицу "Вычисляемые поля" с полями "Выражение" и "Алиас".

Или о чем мы вообще говорим?
...
Рейтинг: 0 / 0
09.10.2008, 14:14
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585705
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
kordaПредставьте таблицу, под которой находится форма с подробностями для каждой записи, вот там и может быть фотография. Пользователь скроллирует записи, а внизу меняются фотографии. При таком подходе фотографию нужно "тянуть" всегда.

Думаю, мы плавно подходим к мысли о необходимости как минимум двух видов форм: для просмотра всей (или почти всей) информации в таблице, и для быстрого выбора из таблицы как из справочника по двум-трем полям. Глубина открытия потрясает :-)

Вообще, я еще раз советую Вам: возьмите какую-нибудь большую программу, интерфейс которой Вам нравится. Проанализируйте типы форм, которые там встречаются. И составьте список фич, которые нужны для полного счастья. А потом уже думайте над автоматизацией рутины. Потому что просто автоматический просмотрщик таблиц, как он у Вас наклевывается, по одной форме на таблицу, будет дубов, неудобен, и вряд ли кому-то нужен; а по сравнению с классическим подходом - еще и страшно труднорасширяем.
...
Рейтинг: 0 / 0
09.10.2008, 14:26
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585762
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
2 Cane Cat Fisher
В чем принципиальная разница между Вашим и моим примерами? В том, что у Вас описание поля и описание выражения никак не связаны. Выражение, для Вас - это лишь некий набор символов. Давайте сделаем так будто, при написании Вашего примера, Вы сделали описку, написав в одном месте в качестве имени таблицы MAN, а в другом - MEN

Код: plaintext
1.
2.
3.
4.
5.
6.
objSQLGen = TSQLGenerator.Create();

objSQLGen.TableName = 'MAN';
objSQLGen.CalcFields.Add('MAN_ADDR', 'CITY.NAME || STREET.NAME || MEN.APART_NUM');

sqlText := objSQLGen.Generate();


Такая ошибка вылезет только в рантайм, и хорошо, если вылезет, так как вполне может быть, что таблица MEN существует!

Теперь, посмотрите у меня.
Символичесое имя (CITY)задано лишь один раз, а дальше лишь программные ссылки на переменную:
Код: plaintext
1.
2.
cityColumn = new Column("CITY", Type.VARCHAR);
...
cityAddress = cityColumn.plus(streetColumn);
...
Рейтинг: 0 / 0
09.10.2008, 14:40
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35585917
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Так... Я вижу, что постепенно втягиваюсь в проект, который реально мне не под силу. Т.е. теоретически, видимо, я смогу сделать, то, что мне требуется, но программа получится сложной и некрасивой, метаданные - уродливыми. И через какое-то время я сам не смогу с ней разобраться. Это то, что случится реально. О чем, вобщем-то, многие предупреждали ( Bely и др.). Помимо этого, Cane Cat Fisher справедливо писал о расширении власти декларативного ядра за счет сужения функций кода, отвечающего за бизнес логику. Да и во мне было какое-то чувство страха перед этим.
Но проблема существует!
Я вот подумал, может быть вместо ядра нужен простой набор утилит, помогающих выполнять так сказать черную работу ? Такие утилиты особо не ограничат свободу, так как использование их не будет необходимым.
...
Рейтинг: 0 / 0
09.10.2008, 15:22
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35586072
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
kordaТакая ошибка вылезет только в рантайм, и хорошо, если вылезет, так как вполне может быть, что таблица MEN существует!

Когда все пишут SQL-запросы вручную, то находятся именно в этой же ситуации. И ничего, живут.

А в метаданных можно с тем же успехом описАться:

Код: plaintext
1.
...
m A nAddress = m E nColumn.plus(manColumn);

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

Для начала сформулируйте, что такое "черная работа" на разных этапах разработки и сопровождения, и сколько процентов времени она отнимает? А какая работа является "белой"?
...
Рейтинг: 0 / 0
09.10.2008, 16:11
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35586306
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher kordaТакая ошибка вылезет только в рантайм, и хорошо, если вылезет, так как вполне может быть, что таблица MEN существует!

Когда все пишут SQL-запросы вручную, то находятся именно в этой же ситуации. И ничего, живут.

А в метаданных можно с тем же успехом описАться:

Код: plaintext
1.
...
m A nAddress = m E nColumn.plus(manColumn);


Разница принципиальная, описка, в приведенном Вами примере - это описка в имени переменной, следовательно выявится уже на этапе компиляции.

Cane Cat Fisher
Когда все пишут SQL-запросы вручную, то находятся именно в этой же ситуации. И ничего, живут.


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

Cane Cat Fisher
Для начала сформулируйте, что такое "черная работа" на разных этапах разработки и сопровождения, и сколько процентов времени она отнимает? А какая работа является "белой"?

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

Если вернуться к Вашему предположению, что таблица MEN существует, то и переменная m E nColumn может существовать. И компиляция пройдет успешно.

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

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

Я, например, не вижу здесь проблемы. Если мне нужно использовать сравнительно сложный SQL-запрос, я сначала набираю его в текстовом файле (FAR, знаете ли, приятная штука), запускаю на исполнение через SQL-консоль много раз, и отлаживаю до полного счастья, отлавливая синтаксис, а заодно посмотрев план. Изменил - перезапустил - смотрю результат - доли секунды. И только потом подкладываю этот файл в папку sqlfiles, откуда от попадает в ресурсы программы. А потом ресурсную строку использую где надо.

kordaМожет быть это не очень точное определение, но черная работа - это та работа, которую можно автоматизировать.

Хм. В данном случае работу автоматизировать несомненно можно, но усилия на это многократно превысят саму работу за несколько месяцев, плюс есть подозрение, что автоматизация никак не покроет все разновидности этой работы, зато заметно усложнит дальнейшую работу за счет непонятного взаимодействия недоавтоматизированной работы с самой ее автоматизацией. Вот.
...
Рейтинг: 0 / 0
09.10.2008, 17:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35589143
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher
Я, например, не вижу здесь проблемы. Если мне нужно использовать сравнительно сложный SQL-запрос, я сначала набираю его в текстовом файле (FAR, знаете ли, приятная штука), запускаю на исполнение через SQL-консоль много раз, и отлаживаю до полного счастья, отлавливая синтаксис, а заодно посмотрев план. Изменил - перезапустил - смотрю результат - доли секунды. И только потом подкладываю этот файл в папку sqlfiles, откуда от попадает в ресурсы программы. А потом ресурсную строку использую где надо.

А я вижу здесь проблему... Описанная методика (набирать запросы в текстовом редакторе) ничем не отличается от того, как работали четверть века назад. Никакой проверки синтаксиса, существования объектов и прочего... Неужели с тех лет ничего не изменилось? Я не в курсе. FAR мне тоже нравится. Но неужели ничего не изменилось с тех лет в плане проектирования запросов?

Вне связи с вышесказанным, я тут "нарыл" один проект, который в каком-то смысле близок к моей цели: Squiggle SQL Builder for Java
Конечно, доверия к нему - никакого, слишком малоизвестный.
...
Рейтинг: 0 / 0
10.10.2008, 22:30
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35589218
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaОписанная методика (набирать запросы в текстовом редакторе) ничем не отличается от того, как работали четверть века назад. Никакой проверки синтаксиса, существования объектов и прочего... Неужели с тех лет ничего не изменилось? Я не в курсе. FAR мне тоже нравится. Но неужели ничего не изменилось с тех лет в плане проектирования запросов?Уже столько лет прошло с изобретения компьютера, а програмисты все пишут и пишут программы... странно, почему еще никто не заменил програмистов

А что касается запросов - то эти запросы со временем становятся все более изощреннее, требования пользователей все более извращеннее.
Поэтому проще спеца обучить SQL, чем разбирать что наконструирует непонимающий пользователь.

PS: а для отладки и написания запросов есть более удобные тулзы, нежели простой NOTEPAD.
Есть и графические конструкторы запросов, но они СИЛЬНО УБОГИЕ.
...
Рейтинг: 0 / 0
11.10.2008, 00:46
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35589791
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Обнаружил родственную тему на этом же форуме:
Как сделать конструктор селектов
...
Рейтинг: 0 / 0
12.10.2008, 02:05
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35590343
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Кажется, приближаюсь к цели!

Что поддерживается на сегодняшний день:

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

Извиняюсь, за неудобочитаемый пример, со временем постараюсь это исправить.

Принцип следующий:
Конструируем JoinBuilder , затем конфигурируем его, в соответствии с условиями задачи и запускаем построение запроса, передав построителю имя для вновь созданного VIEW . См. примеры.

Код: plaintext
1.
2.
3.
4.
5.
JoinBuilder builder0 = new JoinBuilder(Tables.WORKPLACE2.name());
builder0.addColumn(COL_ID, COL_ID);
builder0.addColumn(Workplace2.TYPE.name(), V_Workplace2.W2_TYPE.name());
builder0.addJoin(Workplace2.ZAVAL_ID.name(), Tables.ZAVAL.name());
builder0.addColumn(Zaval.SIZE.name(), V_Workplace2.W2_SIZE.name());
String sql0 = builder0.build(Tables.WORKPLACE2_VIEW_JOIN.name());

Код: plaintext
1.
2.
3.
4.
5.
6.
CREATE VIEW WORKPLACE2_VIEW_JOIN AS SELECT 
T0.ID ID
,T0.TYPE W2_TYPE
,T1.SIZE W2_SIZE
 FROM WORKPLACE2 T0
 LEFT JOIN ZAVAL T1 ON T1.ID=T0.ZAVAL_ID

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
JoinBuilder builder1 = new JoinBuilder(Tables.PERSON_VIEW.name());
builder1.addColumn(COL_ID, COL_ID);
builder1.addColumn(Person.NAME.name(), V_Person.PR_NAME.name());
builder1.addColumn(Person.AGE.name(), V_Person.PR_AGE.name());
builder1.addJoin(Person.WORKPLACE1_ID.name(), Tables.WORKPLACE1_VIEW.name());
builder1.addColumn(COL_ID, V_Person.PR_1_ID.name());
builder1.addColumn(Workplace1.TYPE.name(), V_Person.PR_1_TYPE.name());
builder1.addJoin(Person.WORKPLACE2_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name()+"||"+V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TYPE.name());
builder1.addColumn(V_Workplace2.W2_SIZE.name(), V_Person.PR_SIZE.name());
builder1.addJoin(Person.WORKPLACE2_TWO_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TWO_TYPE.name());
builder1.addJoin(Person.OTHER_PERSON_ID.name(), Tables.PERSON_VIEW.name());
builder1.addColumn(Person.NAME.name(), V_Person.PR_OTHER_NAME.name());
String sql1 = builder1.build(Tables.PERSON_VIEW_JOIN.name());

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE VIEW PERSON_VIEW_JOIN AS SELECT 
T0.ID ID
,T0.NAME PR_NAME
,T0.AGE PR_AGE
,T1.ID PR_1_ID
,T1.TYPE PR_1_TYPE
,T2.W2_TYPE||W2_TYPE PR_2_TYPE
,T2.W2_SIZE PR_SIZE
,T3.W2_TYPE PR_2_TWO_TYPE
,T4.NAME PR_OTHER_NAME
 FROM PERSON_VIEW T0
 LEFT JOIN WORKPLACE1_VIEW T1 ON T1.ID=T0.WORKPLACE1_ID
 LEFT JOIN WORKPLACE2_VIEW_JOIN T2 ON T2.ID=T0.WORKPLACE2_ID
 LEFT JOIN WORKPLACE2_VIEW_JOIN T3 ON T3.ID=T0.WORKPLACE2_TWO_ID
 LEFT JOIN PERSON_VIEW T4 ON T4.ID=T0.OTHER_PERSON_ID
...
Рейтинг: 0 / 0
13.10.2008, 02:17
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35590535
olzhas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olzhas
Гость
Я делал похожую задачу, правда с одним уровнем. Но думаю уровни нарастить не проблема.

как можно сделать в вашем случае.

1. Все метаданные берутся из системных таблиц. Там хранятся первичные и вторичные ключи, наименование полей, таблиц, индексы(если надо будет проверить на производительность) и куча всего.
Единственная проблема это наименование столбцов на Русском языке. Можно было использовать поле description, которое указывается для полей. А можно завести таблицу в которой для поля конкретной таблицы есть имя. Я пошел по второму пути, т.к. у меня 2 языка.

Код: plaintext
1.
2.
3.
4.
5.
CREATE TABLE TEST.FEILDNAME ( 
    TAB_NAME VARCHAR ( 30 )  NOT NULL , 
    FIELD_NAME VARCHAR ( 30 )  NOT NULL , 
    RU_NAME VARCHAR ( 100 )  NOT NULL , 
    KZ_NAME VARCHAR ( 100 )  NOT NULL  , 
    CONSTRAINT FIELD_NAME_PK PRIMARY KEY ( TAB_NAME, FIELD_NAME)  ) ;

2. пользователь указывает таблицу которую он хочет посмотреть.
Мы выполняем такой запрос:
Код: plaintext
1.
2.
3.
4.
select a.TABLE_NAME,a.COLUMN_NAME,c.FKTABLE_NAME,c.FKCOLUMN_NAME, b.RU_NAME 
from sysibm.COLUMNS a
left join test.FEILDNAME b on a.TABLE_NAME=b.TAB_NAME and a.COLUMN_NAME=b.FIELD_NAME
left join sysibm.SQLFOREIGNKEYS c on a.TABLE_NAME=c.PKTABLE_NAME and a.COLUMN_NAME=c.PKCOLUMN_NAME
where TABLE_NAME ='TEST'

По этим данным я думаю не будет стоит труда составить запрос с join-нами.
При чем функция будет одна, просто вызывать ее можно рекурсивно, для FKTABLE_NAME.

на счет алиасов, таблицы нумеруются T1,T2 ... TN
поля же F1,F2 ... FN. + когда мы добавляем поле в запрос мы тут же вставляем его наименование в метаданные результата см. ниже.


данные будут представлены в виде XML. он состот из 2 частей:
1. это метаданные.
2. это сами данные.

ну что то типа

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
<root>
  <meta>
    <field name="f1">ля-ля-ля</field>
    <field name="f2">на-на-на</field> 
  </meta>
  <data>
    <row>
      <fi>value fileld of f1</f1>
      <f2>value fileld of f2</f2>
    </row>
  </data>
</root>
Думаю идея понятна.

p.s. запросы для DB2 но думаю любой БД можно найти аналоги.
...
Рейтинг: 0 / 0
13.10.2008, 09:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35590544
olzhas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olzhas
Гость
Да еще забыл сказать по уровни, уровни это глубина запроса, т.е. количество рекурсии.
Это для того чтобы можно было указывать на сколько подробно пользователь хочет получить данные. + от циклического зависания, на иерархических таблицах.
...
Рейтинг: 0 / 0
13.10.2008, 09:41
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35590670
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
kordaОписанная методика (набирать запросы в текстовом редакторе) ничем не отличается от того, как работали четверть века назад. Никакой проверки синтаксиса, существования объектов и прочего...

Как это никакой проверки синтаксиса? Запустите SQL-запрос, и получите полный диагноз по синтаксису и существованию объектов. Такое ощущение, что для соединения с БД Вам в другой конец города ехать. Честное слово, я перестаю понимать проблему, которую Вы решаете.

kordaJoinBuilder builder0 = new JoinBuilder(Tables.WORKPLACE2.name());

А Вас не смущает, что для "автоматизации запроса" приходится набирать больше символов, нежели в самом запросе? Причем, IMHO, куда менее удобочитаемых и черезполгодасопровождаемых.
...
Рейтинг: 0 / 0
13.10.2008, 10:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35590856
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Cane Cat FisherА Вас не смущает, что для "автоматизации запроса" приходится набирать больше символов, нежели в самом запросе? Причем, IMHO, куда менее удобочитаемых и черезполгодасопровождаемых.+1 !!!

Я об этом писал ранее

авторЧто касается инструмента, который будет создавать SQL запросы - время потраченное на составление схемы данных для такого инструмента будет сопоставимо со временем потраченным на написание самих SQL запросов.
Оно вам надо - делать то же самое, но через задний проход?
...
Рейтинг: 0 / 0
13.10.2008, 11:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35590952
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher
Как это никакой проверки синтаксиса? Запустите SQL-запрос, и получите полный диагноз по синтаксису и существованию объектов. Такое ощущение, что для соединения с БД Вам в другой конец города ехать.


Ну, именно так и писали много лет назад. Набирали текст программы в текстовом редакторе, потом запускали компиляцию, находили номера стро с ошибками в листинге компилятора, затем снова шли в текстовый редактор и исправляли ошибки.
А подсветка синтаксиса?
А отлавливание синтаксических ошибок по мере набора?
А подсказки во время набора?
А удобная работа по сравнению версий?
А проверка орфографии в комментариях?
Я сам поначалу, принципиально, отказывался от всяческих средств разработки и пользовался простейшим текстовым редактором. Потом понял, что мне будет удобнее пользоваться специальными инструментами. Хотя, конечно, это дело весьма субъективное, - одному нравится одно, другому - другое, ведь в каждом подходе есть что-то свое.
...
Рейтинг: 0 / 0
13.10.2008, 12:20
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591001
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher
А Вас не смущает, что для "автоматизации запроса" приходится набирать больше символов, нежели в самом запросе? Причем, IMHO, куда менее удобочитаемых и черезполгодасопровождаемых.

Смущает, конечно... Пытаюсь объективно оценить приемущества и недостатки.

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

Достоинства:
- Нет проблем с синтаксисом, - всегда генерируется синтаксически правильный запрос;
- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);
- Нет проблем со случайным(по ошибке) пересечением имен полей и таблиц, уникальность поддерживается средствами языка.

Что перевешивает? Пока не знаю...
Может быть есть ещё какие-то достоинства и недостатки, которые я упустил?

P.S. У меня нет цели что-либо утвердить подобным решением и у меня нет увереннсти, что оно лучше стандартного подхода, я лишь взвешиваю возможность применения данного подхода в определенных случаях.
...
Рейтинг: 0 / 0
13.10.2008, 12:39
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591011
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
olzhas
1. Все метаданные берутся из системных таблиц.
Идя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно.
...
Рейтинг: 0 / 0
13.10.2008, 12:45
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591035
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
korda- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);В работающей системе переименовывать таблицу вобще не стоит. Даже если она названа с орфографическими ошибками.
Потому что кроме вашей системы данными могут пользоваться ддругие системы, код хранимых процедур в БД.

А на стадии проектирования - все переименования идут на этапе проектирования структуры БД, а не в момент написания кода.

Кроме этого - простая смена имени таблицы легко решается с помощью Search Replace по метаданным или по текстам запросов. Да - это никто не любит делать, но это отнимает не так много времени как все говорят.

Так что выгода от этого - почти неуловимая.
...
Рейтинг: 0 / 0
13.10.2008, 12:53
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591047
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaolzhas
1. Все метаданные берутся из системных таблиц.
Идя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно.Волков бояться - в лес не ходить.

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

После этого - можно достругивать данные вручную.
...
Рейтинг: 0 / 0
13.10.2008, 12:58
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591059
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
olzhas
Единственная проблема это наименование столбцов на Русском языке. Можно было использовать поле description, которое указывается для полей. А можно завести таблицу в которой для поля конкретной таблицы есть имя. Я пошел по второму пути, т.к. у меня 2 языка.


Поле description, к сожалению, поддерживается далеко не всеми БД. И да, Вы правы, оно мало помогает, когда количество языков более одного.
Ваш второй подход поддерживает любое количетсво языков, но не кажется ли Вам, что тексты, - часть пользовательского интерфейса, а не базы данных? Например, чтобы обеспечить моему переводчику возможность исправлять орфографию, я должен предоставлять ему соединение с БД? Я храню все тексты в файлах ресурсов. Кроме текстов, есть ещё иконки, звуки и прочее, что тоже является объектом локализации. Например, при входе в русскоязычную, программу проигрывается слово Привет, а в англоязычную поется - Hello. Читал где-то, что вид почтового ящика российского типа не приемлем в США и наоборот, так как их внешний вид совершенно различен. Таких примеров может быть множество. Только вчера видел english-версию одной программы, где на иконке кнопки сортировки были русские буквы "А" и "Я", как эта иконка "поможет" человеку, не знающему русский, понятно.
...
Рейтинг: 0 / 0
13.10.2008, 13:02
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591095
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Belykorda- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);В работающей системе переименовывать таблицу вобще не стоит. Даже если она названа с орфографическими ошибками.
Потому что кроме вашей системы данными могут пользоваться ддругие системы, код хранимых процедур в БД.
А на стадии проектирования - все переименования идут на этапе проектирования структуры БД, а не в момент написания кода.

Я согласен. Имел ввиду именно - на стадии проектирования.

Bely
Кроме этого - простая смена имени таблицы легко решается с помощью Search Replace по метаданным или по текстам запросов. Да - это никто не любит делать, но это отнимает не так много времени как все говорят.


Search/Replace довльно опасен, нет?...
MY_KILLER_CUSTOMER_TABLE, MY_KILLER_CUSTOMER_COLUMN
MY_KILLER_CUSTOMER_COLUMN переименовать в MY_CUSTOMER_COLUMN
- здесь легко ошибиться и переименовть также и таблицу
...
Рейтинг: 0 / 0
13.10.2008, 13:13
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591098
olzhas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olzhas
Гость
kordaИдя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно.
Хранить это в другом виде ещё более накладно. Где гарантия того что ваше хранилище метаданных будет соответствовать действительности.
А соединение, как получать данные без соединения?
...
Рейтинг: 0 / 0
13.10.2008, 13:14
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591122
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Belykordaolzhas
1. Все метаданные берутся из системных таблиц.
Идя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно.
Можно метаданные брать не постоянно из системных таблиц, а закачать их один раз и далее их дорабатывать.

Все равно метаданные поступают в БД из программы, так лучше, пусть уж там[в программе] и остаются.
...
Рейтинг: 0 / 0
13.10.2008, 13:19
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591133
olzhas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olzhas
Гость
korda
Поле description, к сожалению, поддерживается далеко не всеми БД. И да, Вы правы, оно мало помогает, когда количество языков более одного.
Ваш второй подход поддерживает любое количетсво языков, но не кажется ли Вам, что тексты, - часть пользовательского интерфейса, а не базы данных? Например, чтобы обеспечить моему переводчику возможность исправлять орфографию, я должен предоставлять ему соединение с БД? Я храню все тексты в файлах ресурсов. Кроме текстов, есть ещё иконки, звуки и прочее, что тоже является объектом локализации. Например, при входе в русскоязычную, программу проигрывается слово Привет, а в англоязычную поется - Hello. Читал где-то, что вид почтового ящика российского типа не приемлем в США и наоборот, так как их внешний вид совершенно различен. Таких примеров может быть множество. Только вчера видел english-версию одной программы, где на иконке кнопки сортировки были русские буквы "А" и "Я", как эта иконка "поможет" человеку, не знающему русский, понятно.
Можете хранить в таблице не сами названия а их уникальные идентификаторы. Что бы в дальнейшем в Интерфейсе по идентификатору осуществлять замену. Создавать текстовые фалы с этими идентификаторами и пусть переводчик переводит.
...
Рейтинг: 0 / 0
13.10.2008, 13:23
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35591377
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
korda
- Нет проблем с синтаксисом, - всегда генерируется синтаксически правильный запрос;


Синтаксически - да. Но если допустить ляп в метаданных, то он молча будет неправильным логически. А это отловить куда тяжелее.

korda
- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);


Чего-то я не понял. Ну, переименуйте Person в Man в следующем примере. Или Вы предлагаете оствить в тексте объект Person, и думаете, что это способствует удобочитаемости? По мне так лучше Search/Replace.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
builder1.addColumn(Person.NAME.name(), V_Person.PR_NAME.name());
builder1.addColumn(Person.AGE.name(), V_Person.PR_AGE.name());
builder1.addJoin(Person.WORKPLACE1_ID.name(), Tables.WORKPLACE1_VIEW.name());
builder1.addColumn(COL_ID, V_Person.PR_1_ID.name());
builder1.addColumn(Workplace1.TYPE.name(), V_Person.PR_1_TYPE.name());
builder1.addJoin(Person.WORKPLACE2_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name()+"||"+V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TYPE.name());
builder1.addColumn(V_Workplace2.W2_SIZE.name(), V_Person.PR_SIZE.name());
builder1.addJoin(Person.WORKPLACE2_TWO_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TWO_TYPE.name());
builder1.addJoin(Person.OTHER_PERSON_ID.name(), Tables.PERSON_VIEW.name());
builder1.addColumn(Person.NAME.name(), V_Person.PR_OTHER_NAME.name());
String sql1 = builder1.build(Tables.PERSON_VIEW_JOIN.name());

korda
А подсветка синтаксиса?


В FAR есть.

korda
А отлавливание синтаксических ошибок по мере набора?


Мне кажется, проверять ошибки имеет смысл, только когда запрос набран полностью. Набрали - нажали - проверили.

korda
А подсказки во время набора?


А Вы считате, что в классическом синтаксисе SQL это принципиально невозможно? СтОит ли городить объектную надстройку ради этого?

korda
А удобная работа по сравнению версий?


Ресурсные файлы с SQL-запросами лежат в CVS наравне с другими исходниками.

korda
А проверка орфографии в комментариях?


Если это так существенно, можно набирать запросы в MS Word. А "скрепка с глазами" пусть синтаксис подсказывает :-)
...
Рейтинг: 0 / 0
13.10.2008, 14:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35592942
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
olzhas
Можете хранить в таблице не сами названия а их уникальные идентификаторы. Что бы в дальнейшем в Интерфейсе по идентификатору осуществлять замену. Создавать текстовые фалы с этими идентификаторами и пусть переводчик переводит.
Нечто подобное я и делаю, только идентификаторы у меня тоже находятся за пределами БД, т.е. в программе. Мне нравится такой подход, потому что при нем нет НИКАКОЙ связи между БД и интерфейсом. Завтра кто-то захочет написать свой интерфейс, со своими заголовками полей и своим принципом хранения ресурсов, зачем ему мои идентификаторы?
...
Рейтинг: 0 / 0
14.10.2008, 11:41
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593008
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
2 Cane Cat Fisher

korda
- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);

Cane Cat Fisher
Чего-то я не понял. Ну, переименуйте Person в Man в следующем примере. Или Вы предлагаете оствить в тексте объект Person, и думаете, что это способствует удобочитаемости? По мне так лучше Search/Replace.

Здесь я должен отметить, что пример написан на Java, в котором в некоторых случаях можно прочитать идентификатор в строку. (Те, кто пишет на Java не возмущайтесь, пожалуйста, речь идет о "философском" объяснении, а не о техническом)

Код: plaintext
1.
2.
3.
// На самом деле эта программа не пройдет компиляцию
Integer myKillerInteger =  2 ;
print("This is " + myKillerInteger.name());
Данная программа отпечатает:
Код: plaintext
"This is myKillerInteger"

По поводу остальных вещей.
Можно набирать запросы в FAR, пользоваться command-line CVS клиентом, проверять орфографию вордом,
но можно также все это делать находясь в среде разработки. Я с уважением отношусь к обоим подходам, так как каждый выбирает то, что ему больше по душе. Лично я, поначалу быв сторонником первого, затем стал сторонником второго.
...
Рейтинг: 0 / 0
14.10.2008, 12:00
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593031
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
А вот люди, которые любят вытаскивать данные о связях из системных таблиц , как вы будете поступать в том случае, когда имеете дело не с объектами TABLE , а с какими-нибудь супер-сложными VIEW , ссылочные связи между которыми определить технчески невозможно по сути?
...
Рейтинг: 0 / 0
14.10.2008, 12:07
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593090
olzhas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olzhas
Гость
kordaА вот люди, которые любят вытаскивать данные о связях из системных таблиц , как вы будете поступать в том случае, когда имеете дело не с объектами TABLE , а с какими-нибудь супер-сложными VIEW , ссылочные связи между которыми определить технчески невозможно по сути?
Так вы же не пишете супер универсальную штуку. Давайте тогда и хранимки будем использовать.
...
Рейтинг: 0 / 0
14.10.2008, 12:28
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593104
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaА вот люди, которые любят вытаскивать данные о связях из системных таблиц , как вы будете поступать в том случае, когда имеете дело не с объектами TABLE , а с какими-нибудь супер-сложными VIEW , ссылочные связи между которыми определить технчески невозможно по сути?А что такое "ссылочные связи между VIEW" ?
это вобще бред, если честно.

Ну а если сильно хочется - то можно из сервера вытащить текст запроса и построить по нему все необходимые зависимости.
...
Рейтинг: 0 / 0
14.10.2008, 12:32
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593123
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
olzhaskordaА вот люди, которые любят вытаскивать данные о связях из системных таблиц , как вы будете поступать в том случае, когда имеете дело не с объектами TABLE , а с какими-нибудь супер-сложными VIEW , ссылочные связи между которыми определить технчески невозможно по сути?
Так вы же не пишете супер универсальную штуку. Давайте тогда и хранимки будем использовать.

Нет, я как раз пишу, пусть не супер универсальную, но довольно универсальную штуку.
Единственное(насколько я вижу) оставшееся на сегодняшний день ограничение, так это то, что таблица со справочниками и с самой собой может быть связана лишь по ключу, состоящему из одного поля. Если учесть, что любые связи на основе суррогатных ключей дают именно такую картину, то получается довольно универсальная штука.
...
Рейтинг: 0 / 0
14.10.2008, 12:38
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593158
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
BelykordaА вот люди, которые любят вытаскивать данные о связях из системных таблиц , как вы будете поступать в том случае, когда имеете дело не с объектами TABLE , а с какими-нибудь супер-сложными VIEW , ссылочные связи между которыми определить технчески невозможно по сути?А что такое "ссылочные связи между VIEW" ?
это вобще бред, если честно.

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

>>это вобще бред, если честно.
Так я об этом и "пою".
Есть связь, между таблицами Заказы и Клиенты, на основе этих таблиц построены два VIEW, которые "логически" связаны между собой. Чтобы програмно выявить подобные связи нужно строить анализатор для VIEW.

>>Ну а если сильно хочется - то можно из сервера вытащить текст запроса и построить по нему все необходимые зависимости.
Это и есть анализатор. Понятно, что заниматься им бесперспективно;
...
Рейтинг: 0 / 0
14.10.2008, 12:47
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593170
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Вот скажите - как вяжется вот это:
kordaНет, я как раз пишу, пусть не супер универсальную, но довольно универсальную штуку.вот с этим:
kordaМожно набирать запросы в FAR, пользоваться command-line CVS клиентом, проверять орфографию вордом,
но можно также все это делать находясь в среде разработки . Я с уважением отношусь к обоим подходам, так как каждый выбирает то, что ему больше по душе. Лично я, поначалу быв сторонником первого, затем стал сторонником второго .Вы хорошо понимаете, что написав такую штуку вы низведете среду разработки до обычного редактора, потому что по вашим метаданным - он ничего не сможет вытащить и показать?

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

Я в свое время делал двуязычный интерфейс, который в каждой форме перегружал все лэйблы, выпадающие списки итд. с одного языка на другой.
Находить ошибки на несоответствие названий - было крайне трудно.
...
Рейтинг: 0 / 0
14.10.2008, 12:48
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35593211
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
BelyВы хорошо понимаете, что написав такую штуку вы низведете среду разработки до обычного редактора, потому что по вашим метаданным - он ничего не сможет вытащить и показать?

Ещё как понимаю! Я уже писал об этом, в посте, о недостатках подобной штуки.
Не только низвожу среду до редактора, но и принуждаю разработчика изучить мой доморощенный API.
Вы думаете, если я пишу, то я всем доволен? :) Я вообще не уверен, буду ли использовать этот построитель запросов или нет.
Пока что пробую, размышляю, выявляю, кстати, не без Вашей помощи, узкие места.
...
Рейтинг: 0 / 0
14.10.2008, 13:00
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35594751
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sp
Участник
Тут бы стоило пригласить когонить кто мучаетцца с EAV :))
для обольшинства систем низзя влоб брать и типа пытаться строить запросы по схеме, т.к. сущность может быть сложной , а название связующих элементов в сущности может вводить какую-нить Люсю просто в ступор уже на 2м или 3м уровне интеграции
...
Рейтинг: 0 / 0
15.10.2008, 04:46
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35596289
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
Я бы все же успокоился, и переформулировал задачу заново, чтобы ограничить область наших аппетитов. Например, так:

Проблема: при построении приложений заметное время приходится тратить на написание однообразных "типовых" SQL-запросов вида

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
ВЫБРАТЬ {все | некоторые | все кроме некоторых} поля таблицы
   ИЗ таблицы
      с увязкой по  {всем | некоторым | все кроме некоторых} справочникам, 
         (в том числе многоуровневых), 
         (в том числе циклических - ограничиваясь первым уровнем),

- доставая из увязанных справочников {все | некоторые | все кроме некоторых | заданые по умолчанию | заданые по умолчанию кроме некоторых} поля
- добавляя вычисляемые поля
- добавляя дополнительные WHERE-условия.

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

Предлагается: создать генератор типовых SQL-запросов.

Требования: он должен брать информацию о структуре БД из некого репозитория метаданных (из системных таблиц БД, или каких-то промежуточных - на данном этапе неважно), и принимать аргументами только недостающую, "прикладную" информацию.

Например, есть есть таблицы man (полсотни полей, куча справочников), street и city, и требуется вывести имя человека с адресом, то в классическом случае мы пишем

Query1.SQL := '
SELECT street.name AS streetname, city.name AS cityname, man.housenum, man,apartnum, man.name AS manname
FROM man, street, city
WHERE man.street_id = street.id
AND street.city_id = city.id
AND man.id = :parameter';

А хочется написать как-то так:

Query1.SQL := SQLGenerator.Generate(
tablename => 'man',
fields_only => 'name, housenum, apartnum',
joins_only => 'street' // city по умолчанию подцепится само
where => "man.id = :parameter"
);

То есть, синтаксис аргументов генератора должен примерно соответствовать синтаксической конструкции ВЫБРАТЬ в начале сообщения, то есть поддерживать конструкции "все кроме" и т.д. Если продумать поведение по умолчанию, то можно значительно сократить объем текста для написания типового запроса, и облегчить, а то и вовсе исключить его модификацию при наращивании структуры БД.

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

Вот в таком виде, как мне кажется, задача приобретает хоть какой-то полезный смысл. Главное - незачем дублировать метаданные в тексте программы.
...
Рейтинг: 0 / 0
15.10.2008, 16:27
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597122
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
2 Cane Cat Fisher
Вы знаете, как я ни крутил эту тему (в том числе, разумеется, и в направлении о котором Вы пишите), получаеются такие ограничения, что руки опускаются. Например, элементы вычисляемых полей должны фигурироывть каждый, со своим алиасом, в то время, как эти алиасы генерируются автоматически и на момент описания мета-данных не известны. Ну и много всего другого.
Что с этим делать - не знаю. Начал смотреть в сторону стандартного решения, где SQL-строка. Кстати, в связи с этим вопрос.
Где Вы держите SQL-и? Если в текстовом файле, то каким образом ссылаетесь на них из программы? Я ничего лучшего не придумал, как использовать знаки комментария, а затем указывать имя(ссылку)
Код: plaintext
1.
2.
3.
4.
--select_cust
SELECT * FROM CUSTOMERS

--delete_cust
DELETE FROM CUSTOMERS WHERE ID=?
...
Рейтинг: 0 / 0
16.10.2008, 00:25
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597299
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
аффтар!
Вы бы программиста клиентской части спросили - что ему лучше.
Или пользователя.

Это ж надо - в первом классе изучали - "слой данных не пересакается со слоем отображения".
Вы "какие-то списки полей в БД на клиенте отображаете"

Дерево пытаетесь в плоской вьюхе отобрназить.

Сначала нормализуете БД, потом денормализованное дерьмо пытаетесь на клиента тащить.

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
16.10.2008, 09:06
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597304
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
korda
Где Вы держите SQL-и? Если в текстовом файле, то каким образом ссылаетесь на них из программы?
На сервере законы РСУБД.
На клиенте законы ООП.
Они не пересекаются ===> занимайтесь БД (хранением непротиворечивых данных с точки зрения бизнеса)
...
Рейтинг: 0 / 0
16.10.2008, 09:09
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597306
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Bely
+1

Cane Cat Fisher
+1
...
Рейтинг: 0 / 0
16.10.2008, 09:10
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597393
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
kordaэлементы вычисляемых полей должны фигурироывть каждый, со своим алиасом, в то время, как эти алиасы генерируются автоматически и на момент описания мета-данных не известны

Чтобы они были известны, нужно отказаться от промелькнувшей ранее мысли генерировать их со сквозным порядковым номером, и вернуться к вопросу о разумном алгоритме наименования алиасов. Если он будет очевидным, то прикинуть его "в уме" и понять имена будущих алиасов будет несложно.
В крайнем случае, можно значала описать SQL-запрос, просмотреть его текст в каком-то отладочном режиме, и посмотреть, что там за алиасы. А потом уже добавить вычисляемые поля.

А вообще, еще раз говорю - задача достаточно сложная. Если главная проблема - сэкономить время сейчас, то лучше и не влезайте.
...
Рейтинг: 0 / 0
16.10.2008, 09:54
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597414
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Petro123korda
Где Вы держите SQL-и? Если в текстовом файле, то каким образом ссылаетесь на них из программы?
На сервере законы РСУБД.
На клиенте законы ООП.
Они не пересекаются ===> занимайтесь БД (хранением непротиворечивых данных с точки зрения бизнеса)

2 Petro123

В небе - самолет.
У меня на столе чай.
Они не пересекаются ===> занимайтесь йогой (постижением мира с точки зрения себя)

P.S. Что-то я не понял, каким образом Ваши слова комментируют вопрос о способе хранения SQL-стрингов.
...
Рейтинг: 0 / 0
16.10.2008, 10:03
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597506
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
это был пост на все 5 старниц (прочитал)
IMHO
- не увидел проблему (в чём трудоёмкость?)
- На первой странице вы писали. что у вас был опыт построения системы с ХОРОШИМИ выводами. Вы даже "рукописи свои потом сожгли".
- фреймворк пишите?
авторАвтоматизация запросов.
для кого?


ЗЫ. Запрос я пишу и отлаживаю в PSQL Developer (там всё есть, я вас уверяю).
Затем либо делаю вьюху, либо ХП и дёргаю её с клиента за 2 клика мышкой в своей RAD

"Сложнее всего в мире достигнуть простоты - это крайняя граница опыта и последнее усилие гения".
George Sand.
...
Рейтинг: 0 / 0
16.10.2008, 10:26
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35597767
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaЯ ничего лучшего не придумал, как использовать знаки комментария, а затем указывать имя(ссылку)На клиенте - XML, на сервере - просто положить в таблички.
...
Рейтинг: 0 / 0
16.10.2008, 11:35
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598089
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Petro123это был пост на все 5 старниц (прочитал)
IMHO
- не увидел проблему (в чём трудоёмкость?)
- На первой странице вы писали. что у вас был опыт построения системы с ХОРОШИМИ выводами. Вы даже "рукописи свои потом сожгли".
- фреймворк пишите?
авторАвтоматизация запросов.
для кого?


ЗЫ. Запрос я пишу и отлаживаю в PSQL Developer (там всё есть, я вас уверяю).
Затем либо делаю вьюху, либо ХП и дёргаю её с клиента за 2 клика мышкой в своей RAD

"Сложнее всего в мире достигнуть простоты - это крайняя граница опыта и последнее усилие гения".
George Sand.

По большому счету проблема в интеграции языка SQL и языка программирования.
С точки зрения языка программирования SQL-предложения - обычные строки. Из этого вытекает то, что находясь в среде разработки программы, я не получаю НИКАКИХ сервисов в отношении SQL. Ни тебе подсветки синтаксиса, ни синтаксических проверок, ни списка таблиц/полей, в качестве подсказки и т.д. Получается, что работать с запросами, которые заданы в программе, как строки - неудобно. Если бы , был программный API к БД, всё бы решалось отлично. И такие вещи существуют. Всякие объектно-ориентированные БД. Но насколько я понял, они в достаточно зачаточном состоянии. Этот коммерческий трюк, когда приводят пример с таблицей, в которую нужно добавить/изменить/удалить запись, вызывает негативные эмоции. Потому, что когда дело доходит до чего-то более сложного, чем SELECT * FROM my_table , то неясно как это можно реализовать средствами системы. Ни примеров, ни документации... Полагаю. это от отсутствия видения проблемы в целом. Кстати, мое видение проблемы неоднократно менялось в ходе данного обсуждения. Люди видели проблемы там, где я их поначалу не замечал. В целом проблема философская. Если бы среда разработки каким-то образом знала, что данная строка используется в качестве SQL-предложения и давала бы все необходимые разработчику сервисы, то и не было бы проблемы. Кстати, существуют-же языки, в которых SQL фигурирует не в виде строки, а является частью синтаксиса. Вся наша дискуссия будет совершенно непонятна программисту FoxPro, так как в этом языке SQL - конструкция языка, и нет никакой необходимости в задании даже имен полей в виде строк, - все переменные.
...
Рейтинг: 0 / 0
16.10.2008, 13:04
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598103
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
BelykordaЯ ничего лучшего не придумал, как использовать знаки комментария, а затем указывать имя(ссылку)На клиенте - XML, на сервере - просто положить в таблички.

Если XML, то легко находить нужный запрос, это плюс. Но теряется выгода от применения средств разработки. Они ведь будут работать с *.sql файлами и не будут с *.xml
...
Рейтинг: 0 / 0
16.10.2008, 13:09
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598492
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
kordaPetro123
"Сложнее всего в мире достигнуть простоты - это крайняя граница опыта и последнее усилие гения".
George Sand.

По большому счету проблема в интеграции языка SQL и языка программирования.
С точки зрения языка программирования SQL-предложения - обычные строки.

======= ЯП тоже отдельные строки. НЕотдельными их видит компилятор, у каждого ЯП _он свой_

Из этого вытекает то, что находясь в среде разработки программы, я не получаю НИКАКИХ сервисов в отношении SQL.

====== не вытекает. Вас не смущает вставка в Word рисунка выполненного в Фотошоп?

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

==== sql не ЯП разработки клиента. Это ЯП бизнес-логики сервера. БЛ должна быть на сервере. У каждого сервера свой IDE для SQL (я в нём работаю, и на клиенте у меня вызовы CRUD)

Получается, что работать с запросами, которые заданы в программе, как строки - неудобно. Если бы , был программный API к БД, всё бы решалось отлично. И такие вещи существуют.

=== см.выше

Всякие объектно-ориентированные БД. Но насколько я понял, они в достаточно зачаточном состоянии.

=== да. Плюнь на ООБД (пока)

В целом проблема философская.

= нет проблемы. Один рисует картины, другой делает под них рамки.

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

ЯП SQL будет жить очень долго, пока не появятся ООП хранилища вместо РСУБД.
Основное правило ООП - инкапсуляция . Т.е. язык БД не должен лезть на клиента. Запихни всю свою логику в понятную процедуру

Код: plaintext
ПакетРасчётаЗарплаты.НасчитатЕНВД(период).
на клиенте неинтересен твой SQL. А если это Вэб клиент? Или Excell клиент?
Смотри шире.
...
Рейтинг: 0 / 0
16.10.2008, 15:02
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598517
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
kordaBelykordaЯ ничего лучшего не придумал, как использовать знаки комментария, а затем указывать имя(ссылку)На клиенте - XML, на сервере - просто положить в таблички.

Если XML, то легко находить нужный запрос, это плюс.

====== я всегда сомневался, что кто-то за меня найдёт нужную процедуру при написании программы

Но теряется выгода от применения средств разработки. Они ведь будут работать с *.sql файлами и не будут с *.xml

= кто ОНИ. Пользователь Маша Петрова? Очень сомневаюсь (хотя я делал одну такую - сохранял просто Where строку).
...
Рейтинг: 0 / 0
16.10.2008, 15:06
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598650
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Petro123
на клиенте неинтересен твой SQL.

Хм... С этим невозможно не согласиться...
Но как это будет выглядеть практически? На каждый SELECT/INSERT/UPDATE и т.д. писать stored procedure? Наверное, это будет правильным. Трагедикомедия заключается в том, что эти stored procedures мне придется писать на Java (БД поддерживает ТОЛЬКО его). Кстати, клиент тоже на Java. Вот и получается, что находится на стороне сервера и клиента, суть одно и тоже (в плане разработки) Т.е. даже на стороне сервера буду иметь язык программирования и стринги SQL-я.
...
Рейтинг: 0 / 0
16.10.2008, 15:40
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598676
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
kordaPetro123
на клиенте неинтересен твой SQL.

Хм... С этим невозможно не согласиться...
Но как это будет выглядеть практически? На каждый SELECT/INSERT/UPDATE и т.д. писать stored procedure?

===== почему на каждый? Всё изобретено до нас. Есть 2 подхода. Я за БЛ на сервере. И есть 2 подхода - я НЕ за CRUD в чистом виде (с закрытием доступа к таблицам), а за CRUD в сложных транзакционных бизнес-процедурах. Для справочников он не нужен. А для "ЗакрытиеОперДня" обязателен.

Наверное, это будет правильным. Трагедикомедия заключается в том, что эти stored procedures мне придется писать на Java (БД поддерживает ТОЛЬКО его).

==== ну и отлично. У Сиквел 2005 тоже появился ЯП одинаковый с клиентом.

Кстати, клиент тоже на Java. Вот и получается, что находится на стороне сервера и клиента,

===== хуже только административно (см.ниже)

суть одно и тоже (в плане разработки) Т.е. даже на стороне сервера буду иметь язык программирования и стринги SQL-я.

==== с чего бы? Как зависит ЯП от CRUD? 2-ое, это методология, а первое?


ЗЫ.
Когда язык сервера и клиента разный, это на руку архитектору Системы в целом, т.к. архитектор БД не тянет одеяло у архитектора клиента.
Кесарю-кесарево.
У первого и мозги заточены на мышление множествами а не объектами . Поэтому второй не сможет строить оптимальные и сложные запрос как оптимизатор
ИМХО
...
Рейтинг: 0 / 0
16.10.2008, 15:53
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598684
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
авторТ.е. даже на стороне сервера буду иметь язык программирования и стринги SQL-я.
ааа. счас дошло.
Я не знаю какой там язык, но если он заточен под обработку множеств, курсоров, и прочей лабуды, то на здоровье.

Кстати в оракле, если не динамический стринг, то синтаксическая проверка тоже есть.
ЕСТЬ ТАМ всё, выбери только иструмент для твоей БД.

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
16.10.2008, 15:56
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598691
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Идея держать всю логику в stored procedures определённо нравится. Вобщем-то, это давно известная вещь. Просто, в последнее время, в поисках истины, просмотрел много всяких клент-сервер приложений различной направленности, и все они держали SQL-строки на стороне клиента, это как-то сбило меня с пути истинного.

Но практическая проблема при этом никуда не девается. Даже находясь на сервере работать со сложными запросами не удобно, по причине отсутствия логической связи между SQL и языком программирования.
...
Рейтинг: 0 / 0
16.10.2008, 15:57
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598715
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
korda
Но практическая проблема при этом никуда не девается. Даже находясь на сервере работать со сложными запросами не удобно, по причине отсутствия логической связи между SQL и языком программирования.
бренность бытия. Его несовершенство :)
Я в одно время очень искал ООБД, пок ане понял что ОНО не совершенно ))
ЗЫ. Твои вопросы возникают у тех кто пишет на ЯП, который движется в сторону ООП. У реляционщиков он не возникает.
Удачи!

ЗЫ.ЗЫ. Если нужны справочник, то
- напиши ХП_ДайСправочник(имя) : курсор
- на клиенте одну форму для всех справочников или выпадающий список для всех справочников (и писать не надо)

вот где имена полей по русски - да - проблема.
...
Рейтинг: 0 / 0
16.10.2008, 16:05
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35598860
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaИдея держать всю логику в stored procedures определённо нравится.Заставь дурака богу молиться...

Вот ситуация - есть у нас ХП (или хранимая функция), которая возвращает ВСЕ организации.
Теперь приложению надо отфильтровать этот результат - выбрать только организации, которые находятся в Москве.

Как вы думаете - сколько шансов у сервера БД оптимизировать этот запрос, нежели просто сделать FULL SCAN по ВСЕМ данным?

Код: plaintext
1.
2.
SELECT t.*
FROM MyFun_AllOrg() t
WHERE t.city = 'Москва'

Чтобы сервер БД мог использовать индексы и прочие свои прелести для оптимизации запроса, то мы можем передавать параметр "Москва" ВНУТРЬ ХП.

Код: plaintext
1.
SELECT t.*
FROM MyFun_AllOrg(p_city => 'Москва') t
Тогда это параметр можно будет подставить непосредственно в SQL statment внутри ХП.
Но тогда встает другая проблема - нам в ХП придется описывать в качестве входных параметров фиг знает сколько переменных, чтобы уметь по ним фильтровать.

И это все, вместо того, чтобы в программе динамически сформировать запрос вида:
Код: plaintext
1.
2.
3.
4.
SELECT t.*, c.name as city_name, a.street, a.house, a.office
FROM all_org t, city_list c, org_address a
WHERE c.city = 'Москва'
  and c.city_id = t.city_id
  and t.addr_id = a.addr_id
так что ХП - это врядли выход.
...
Рейтинг: 0 / 0
16.10.2008, 16:50
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599016
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Bely
Чтобы сервер БД мог использовать индексы и прочие свои прелести для оптимизации запроса, то мы можем передавать параметр "Москва" ВНУТРЬ ХП.

Код: plaintext
1.
SELECT t.*
FROM MyFun_AllOrg(p_city => 'Москва') t
Тогда это параметр можно будет подставить непосредственно в SQL statment внутри ХП.
Но тогда встает другая проблема - нам в ХП придется описывать в качестве входных параметров фиг знает сколько переменных, чтобы уметь по ним фильтровать.

И это все, вместо того, чтобы в программе динамически сформировать запрос вида:
Код: plaintext
1.
2.
3.
4.
SELECT t.*, c.name as city_name, a.street, a.house, a.office
FROM all_org t, city_list c, org_address a
WHERE c.city = 'Москва'
  and c.city_id = t.city_id
  and t.addr_id = a.addr_id
так что ХП - это врядли выход.

1. Да, придется передавать кучу параметров. А что, чтобы динамически построить SELECT на клиенте, в процедуру-построитель эти параметры передавать не нужно?!
А если учесть, что и сервер и клиент у меня пишутся на одном и том-же языке, то процедура вообще получается одна и та же.

2. Если ВСЯ бизнес-логика будет крутиться на сервере, то мы имеем сервер в виде законченного продукта , к нему можно делать различные клиенты, не знающие внутреннюю логику и структуру сервера(не зачем им это знать).
...
Рейтинг: 0 / 0
16.10.2008, 17:37
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599030
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
korda1. Да, придется передавать кучу параметров. А что, чтобы динамически построить SELECT на клиенте, в процедуру-построитель эти параметры передавать не нужно?!
А если учесть, что и сервер и клиент у меня пишутся на одном и том-же языке, то процедура вообще получается одна и та же.На клиенте эта куча параметров у вас есть в виде контролов в форме поиска из которых строится строка WHERE.

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

korda2. Если ВСЯ бизнес-логика будет крутиться на сервере, то мы имеем сервер в виде законченного продукта , к нему можно делать различные клиенты, не знающие внутреннюю логику и структуру сервера(не зачем им это знать).Ну-ну... безумству храбрых поем мы песню.
А знать названия хранимых процедур, которые вызывать приложение не должно?
И чем это будет отличаться от знания структуры таблиц в БД?

Заменили синее на коричневое и радуемся...
...
Рейтинг: 0 / 0
16.10.2008, 17:41
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599113
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Belykorda
[quot korda]2. Если ВСЯ бизнес-логика будет крутиться на сервере, то мы имеем сервер в виде законченного продукта , к нему можно делать различные клиенты, не знающие внутреннюю логику и структуру сервера(не зачем им это знать).Ну-ну... безумству храбрых поем мы песню.
А знать названия хранимых процедур, которые вызывать приложение не должно?
И чем это будет отличаться от знания структуры таблиц в БД?

Заменили синее на коричневое и радуемся...

Знать названия и параметры хранимых процедур и знать структуру БД - это не одно и тоже. Первое - внешний интерфейс к БД, второе - внутренняя структура БД.
Завтра, у меня вместо одной таблицы будет две. Изменю сервер. При этом клиент ничего знать об этом не будет(и не должен), все изменения будут скрыты внутри хранимой процедуры.
...
Рейтинг: 0 / 0
16.10.2008, 18:06
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599144
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaЗнать названия и параметры хранимых процедур и знать структуру БД - это не одно и тоже. Первое - внешний интерфейс к БД, второе - внутренняя структура БД.
Завтра, у меня вместо одной таблицы будет две. Изменю сервер. При этом клиент ничего знать об этом не будет(и не должен), все изменения будут скрыты внутри хранимой процедуры.в 90% случаях при этом будут меняться и ХП, а значит, всеравно, придется переделывать и клиента.
...
Рейтинг: 0 / 0
16.10.2008, 18:21
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599207
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
kordaИдея держать всю логику в stored procedures определённо нравится. Вобщем-то, это давно известная вещь. Просто, в последнее время, в поисках истины, просмотрел много всяких клент-сервер приложений различной направленности, и все они держали SQL-строки на стороне клиента, это как-то сбило меня с пути истинного.

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

SQL строки на клиенте таки придется "держать". Те же фильтры, например. Можно, конечно, передавать параметры в хранимую процедуру, но, мне кажется, строить выражение для выборки на клиенте проще. Больше доступных данных.
...
Рейтинг: 0 / 0
16.10.2008, 18:53
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599218
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
korda
Знать названия и параметры хранимых процедур и знать структуру БД - это не одно и тоже. Первое - внешний интерфейс к БД, второе - внутренняя структура БД.
Завтра, у меня вместо одной таблицы будет две. Изменю сервер. При этом клиент ничего знать об этом не будет(и не должен), все изменения будут скрыты внутри хранимой процедуры.

Блин. Еще один любитель изменять БД, "незаметно для клиента".
Да клиент меняется многократно чаще и, большей частью, именно во взаимодействии с БД.
И, например, добавление полей в фильтр - достаточно частое изменение.

Если формировать запрос на клиенте, то, как раз, наоборот, на сервере ничего менять не придется. А если использовать ХП с параметрами, то наоборот - довольно много. Причем надо будет помнить еще и обо всех остальных парнях, которые используют эту процедуру.
...
Рейтинг: 0 / 0
16.10.2008, 19:00
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599223
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
Bely
И это все, вместо того, чтобы в программе динамически сформировать запрос вида:
Код: plaintext
1.
2.
3.
4.
SELECT t.*, c.name as city_name, a.street, a.house, a.office
FROM all_org t, city_list c, org_address a
WHERE c.city = 'Москва'
  and c.city_id = t.city_id
  and t.addr_id = a.addr_id
так что ХП - это врядли выход.
Опять опеределили. Да чтож такое....
...
Рейтинг: 0 / 0
16.10.2008, 19:03
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599242
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Николай1Опять опеределили. Да чтож такое....Пока ваш конь 1-2-3-4 мы тут 1-2,1-2
...
Рейтинг: 0 / 0
16.10.2008, 19:13
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599397
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
BelyНиколай1Опять опеределили. Да чтож такое....Пока ваш конь 1-2-3-4 мы тут 1-2,1-2

Ну, ничего, мы себя в !@#$ покажем!
...
Рейтинг: 0 / 0
16.10.2008, 21:21
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599434
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
imho
условие where в ХП - чересчур.
Так можно и order by пихать на основании, что это структура БД.
ЗЫ.
Был у меня проект с кучей where на клиенте

Код: plaintext
1.
2.
3.
4.
if галка1 then
 Query.Add(' and (t.dddd>2008)') 
......................................
if галкаN then
 Query.Add(' and (t.kkk>combo.items[n])')

при рефакторинге (надо было ещё одно сложное условие) просто добаил ХПGetAddWhere(id) и
дописал на клиенте


Код: plaintext
1.
if галкаN then
 Query.Add(' and (ХПGetAddWhere(t.id)=1')
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
16.10.2008, 22:00
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599548
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Николай1[quot korda]
Знать названия и параметры хранимых процедур и знать структуру БД - это не одно и тоже. Первое - внешний интерфейс к БД, второе - внутренняя структура БД.
Завтра, у меня вместо одной таблицы будет две. Изменю сервер. При этом клиент ничего знать об этом не будет(и не должен), все изменения будут скрыты внутри хранимой процедуры.

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

Николай1Если формировать запрос на клиенте, то, как раз, наоборот, на сервере ничего менять не придется.
А если имеется внутренняя бизнес-логика сервера, в клиенте её держать?
Клиент может быть написан третьей стороной, для которой знание бизнес-логики сервера может быть вообще запрещено исходя из требований секретности.

Вот при всем уважении, Николай, Ваши сегодняшние утверждения, выглядят как попытка просто противоречить.
...
Рейтинг: 0 / 0
16.10.2008, 23:21
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599566
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Николай1Bely
И это все, вместо того, чтобы в программе динамически сформировать запрос вида:
Код: plaintext
1.
2.
3.
4.
SELECT t.*, c.name as city_name, a.street, a.house, a.office
FROM all_org t, city_list c, org_address a
WHERE c.city = 'Москва'
  and c.city_id = t.city_id
  and t.addr_id = a.addr_id
так что ХП - это врядли выход.
Опять опеределили. Да чтож такое....

Чему Вы радуетесь? :-) Bely предлагает динамически формировать запрос вытаскивая данные прямо из UI.

По-моему, г-н Bely не учел две вещи:
1. Когда в динамическом запросе присутствуют controlы GUI, то возникает пролема с batch-тестами.
2. После dispose в некоторых системах GUI данные становятся недоступными. А ведь иногда нужно закрыть диалог(т.е. dispose all controls), а уж потом запустить запрос на выполнение.
...
Рейтинг: 0 / 0
16.10.2008, 23:32
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599612
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
kordaПо-моему, г-н Bely не учел две вещи:
1. Когда в динамическом запросе присутствуют controlы GUI, то возникает пролема с batch-тестами.
2. После dispose в некоторых системах GUI данные становятся недоступными. А ведь иногда нужно закрыть диалог(т.е. dispose all controls), а уж потом запустить запрос на выполнение.откройте для себя шаблон Model-View-Controller, при его использовании эти вопросы теряют почти всю свою актуальность
...
Рейтинг: 0 / 0
17.10.2008, 00:03
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599704
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
egorychkordaПо-моему, г-н Bely не учел две вещи:
1. Когда в динамическом запросе присутствуют controlы GUI, то возникает пролема с batch-тестами.
2. После dispose в некоторых системах GUI данные становятся недоступными. А ведь иногда нужно закрыть диалог(т.е. dispose all controls), а уж потом запустить запрос на выполнение.откройте для себя шаблон Model-View-Controller, при его использовании эти вопросы теряют почти всю свою актуальность

Вот, интересно было бы увидеть, не таблицу и не дерево, а какой-нибудь диалог с input-полями, построенный по этому принципу. Правда, то что так мало кто делает совсем не означает, что это плохо.
...
Рейтинг: 0 / 0
17.10.2008, 01:10
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599720
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
К слову, я тут нарыл одну интересную статью Тенцер А. База данных – хранилище объектов // КомпьютерПресс. 2001. № 8.
Судя по году издания и огромному количеству высказываний по ней, даже в рамках этого форума, многие с ней знакомы, но для начинающих, возможно окажется полезной.

Как эта статья связана с Темой? На основе предлагаемого в ней метода можно построить ряд универсальных таблиц, запросы к которым, в свою очередь тоже будут универсальны. В подходе Тенцера етсь ряд недостатков, о которых пишет он и его критики. Я пока еще не вник глубоко и не могу оценить для себя возможность следовать данной концепции.
...
Рейтинг: 0 / 0
17.10.2008, 01:27
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599917
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
kordaНиколай1korda
Знать названия и параметры хранимых процедур и знать структуру БД - это не одно и тоже. Первое - внешний интерфейс к БД, второе - внутренняя структура БД.
Завтра, у меня вместо одной таблицы будет две. Изменю сервер. При этом клиент ничего знать об этом не будет(и не должен), все изменения будут скрыты внутри хранимой процедуры.

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

Это и есть реальный недостаток. Если сделать ХП с 20 параметрами (по количеству контролов, например), то это гораздо жестче привяжет базу к клиенту, чем передача запроса в виде одного параметра.

kordaНиколай1Если формировать запрос на клиенте, то, как раз, наоборот, на сервере ничего менять не придется.
А если имеется внутренняя бизнес-логика сервера, в клиенте её держать?
Клиент может быть написан третьей стороной, для которой знание бизнес-логики сервера может быть вообще запрещено исходя из требований секретности.

Нет никаких проблем поправить запрос, сформированный на клиенте, внутри ХП. Так что все в порядке, клиент занимается своей работой, сервер - своей. Никто же не утверждал, что запрос от клиента надо передавать серверу "напрямую".
...
Рейтинг: 0 / 0
17.10.2008, 08:59
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35599947
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
давайте не будем про тенцера, eav, ообд, xmldb и т.д
Есть в мире много чего интересного, но это OFFTOP
Удачи!
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
17.10.2008, 09:21
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35600166
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
kordaКак эта статья связана с Темой? На основе предлагаемого в ней метода можно построить ряд универсальных таблиц, запросы к которым, в свою очередь тоже будут универсальны. .... Я пока еще не вник глубоко и не могу оценить для себя возможность следовать данной концепции.Мда... начали с построителя запросов, закончили EAV.
Вы бы сперва вникли в эту структуру, а потом подумали как бы вы из нее доставали бы данные для пользователя, которые ему понадобятся.
...
Рейтинг: 0 / 0
17.10.2008, 10:46
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35600594
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
BelyМда... начали с построителя запросов, закончили EAV.

Верный признак того, что главной решаемой проблемой является "А давайте сделаем что-нибудь универсальное!!!" :-)
...
Рейтинг: 0 / 0
17.10.2008, 12:40
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35613719
KOT MATPOCKuH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KOT MATPOCKuH
Участник
Осилил...
Но так и не понял - какую функциональность обсуждаем.
Исходная задача стояла (если я правильно понял): по некоторому набору сущностей выдать SQL-запрос, возвращающий все их поля, объединив все эти таблицы (и возможно промежуточные их связывающие).
В силу ряда неучтенных при постановке задачи факторов (названия полей, множественные связи, циклические ссылки и др.) задача перестала быть понятной вообще.

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

Т.е. в процессе программирования, например этого:
автор
builder1.addColumn(Person.NAME.name(), V_Person.PR_NAME.name());
builder1.addColumn(Person.AGE.name(), V_Person.PR_AGE.name());
builder1.addJoin(Person.WORKPLACE1_ID.name(), Tables.WORKPLACE1_VIEW.name());
builder1.addColumn(COL_ID, V_Person.PR_1_ID.name());
builder1.addColumn(Workplace1.TYPE.name(), V_Person.PR_1_TYPE.name());
builder1.addJoin(Person.WORKPLACE2_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name()+"||"+V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TYPE.name());
builder1.addColumn(V_Workplace2.W2_SIZE.name(), V_Person.PR_SIZE.name());
builder1.addJoin(Person.WORKPLACE2_TWO_ID.name(), Tables.WORKPLACE2_VIEW_JOIN.name());
builder1.addColumn(V_Workplace2.W2_TYPE.name(), V_Person.PR_2_TWO_TYPE.name());
builder1.addJoin(Person.OTHER_PERSON_ID.name(), Tables.PERSON_VIEW.name());
builder1.addColumn(Person.NAME.name(), V_Person.PR_OTHER_NAME.name());
String sql1 = builder1.build(Tables.PERSON_VIEW_JOIN.name());

Автор собирается продумывать - а что ему на самом деле нужно! Т.е. какие данные (поля и колонки) ему нужно получить конкретно в этом месте.
Причем, замечу, пишется код клиента (я не ошибся?)
Т.е. вряд ли этот код постоянно будет правиться, только при изменениях БЛ (ну и баги конечно).

Возник вопрос: А зачем все это нужно?
Варианты ответов:
1) Автор плохо дружит с SQL и хотел бы придумать ему замену, то это одно.
2) Автор хочет используя какой-то инструмент себе (разработчику) облегчить жизнь по формированию простых запросов.
3) Автор придумывает инструмент для пользователя

я все варианты учел?

1) Дело не благодарное и никому, в том числе автору (если он еще этого не понял) не нужное
2) Автор мог бы воспользоваться одним из многих построителей запросов или написать свой. Либо - см. далее, т.к. программист - он тоже немного пользователь :))
3) Тут все зависит от интерфейса. Вариантов можно навыдумывать много.

Предложу следующий (с кучей проблем, но простой):
На экране слева - дерево, справа - результат (либо данные запроса, либо SQL-запрос, либо - оба)
Дерево - на первом уровне содержит сущности. Открывая сущность T1 видим все ее поля. Можем включить поля в запрос. Для FK-полей - можно раскрыть - увидев поля связанной таблицы, которые тоже можно включать или нет, но можно снова раскрыть ее FK-поля и т.д. Проблем с вложенностью циклических запросов - нет, т.е. сколько нада - столько открываем.

Уточнения:
1) Сущности: результирующий запрос будет включать в себя все сущности от первого уровня - до сущности самого нижнего уровня (в каждой ветке), поля которой включены в запрос.
2) Связи: Со связями вопросов не возникает - они строятся по дереву, между конкретными полями конкретных экземпляров сущностей
3) Список полей в результате: все "отмеченные".
4) Именование сущностей (алиасы таблиц): При выборе полей из данной сущности или "нижних" - проверка на уникальность экземпляра. В случае нарушения - переименовать в уникальный, спросить у пользоватея в конце концов.
5) Именование полей (алиасы полей): При выборе полей - проверка на уникальность имени (алиаса). В случае нарушения - переименовать в уникальный, спросить у пользоватея в конце концов.
6) Вычисляемые поля - это такое же поле в списке, как и все остальные (метаданные нужно создавать под результат)

Результат:
Что делать с результатом - решать тому, кто использует.
- Программист может сформировать VIEW, ХП, просто скопировать запрос, сохранить в XML или еще куда.
- Пользователь что-то будет делать с данными (аналитика, печать? и т.д. и т.п.)

Что для этого нужно:
1) Репозитарий метаданных (+инструмент по его формированию)
2) Руки - для програмирования, немного мозга - для фантазии по развитию темы
3) Пиво
...
Рейтинг: 0 / 0
24.10.2008, 09:59
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35614095
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
KOT MATPOCKuH
Возник вопрос: А зачем все это нужно?
Варианты ответов:
1) Автор плохо дружит с SQL и хотел бы придумать ему замену, то это одно.
2) Автор хочет используя какой-то инструмент себе (разработчику) облегчить жизнь по формированию простых запросов.
3) Автор придумывает инструмент для пользователя

я все варианты учел?


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

Правда, предложенный автором механизм автоматизации оказался куда сложнее и трудоемче исходных SQL-текстов, но тут уж я не виноват :-)

То есть, все сводится к вариации варианта 2 - "Автор хочет используя какой-то инструмент себе (разработчику) облегчить жизнь по формированию простых запросов."

KOT MATPOCKuH
Автор мог бы воспользоваться одним из многих построителей запросов или написать свой.


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

Идея автоматического построения запросов "на лету" в том, чтобы добавленный справочник "подхватился" автоматически. (предполагается, что именно такое действие по умолчанию требуется от большинства SQL-запросов для нового справочника). И лишь в одном-двух местах, "где не надо" - меняем параметры вызова генератора. Осознав и автоматизировав требуемое дефолтовое поведение, сводим к минимуму правку кода при типичном развитии системы - вот главная цель.
...
Рейтинг: 0 / 0
24.10.2008, 11:59
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35617363
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Cane Cat FisherKOT MATPOCKuH
Возник вопрос: А зачем все это нужно?

так, как протелепатировал проблему я. Дело в том, что, по мнению автора, во многих приложениях заметная часть SQL-запросов строится по простейшему принципу "выбрать все из этой таблицы плюс справочники". Написание таких запросов сводится к нетворческому перечислению имен полей и таблиц по жесткому шаблону, отнимает заметное время при создании и развитии системы, и может быть автоматизировано. Тут я бы с ним согласился.
я бы не согласился:
- ЭТО не занимает заметное время (на сервере простые JOIN со справочниками не пишут, а на клиенте в доле времени разработки формы - оно ничтожно)
- на клиенте НЕ нужен перечень всех полей (это вредно по рессурсам, это плохо при проетировании ВИ/ГУИ/... и на это есть ГОТОВЫЕ клиентские построители и библиотеки)
- автоматизируют там где тонко, а не там где светло
...
Рейтинг: 0 / 0
27.10.2008, 10:52
| Ответить | Цитировать | Написать  
Оперативный файл и справочники. Автоматизация запросов.
    #35642727
korda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
korda
Гость
Cane Cat Fisher очень точно и понятно описал суть проблемы, даже лучше, чем сам автор (т.е. я).
Прошло довольно много времени с момента начала обсуждения. Сказать, что дело заметно сдвинулось с мертвой точки я не могу... Однако, общение по Теме было небесполезным, я узнал много интересного, за что спасибо всем участникам обсуждения.
На сегодняшний день практикую следующее - джоины пишу "раками", прямо в тексте программы. Из всех умничаний осталось лишь одно - имена полей держу в переменных, так проще делать рефакторинг. Сказать, что я доволен не могу. Это что-то вроде компромисного варианта.
...
Рейтинг: 0 / 0
09.11.2008, 22:03
| Ответить | Цитировать | Написать  
154 сообщений из 154, показаны все 7 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оперативный файл и справочники. Автоматизация запросов.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1543584]:
 0ms
get settings:
 8ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 243ms
get topic data:
 14ms
get forum data:
 4ms
get page messages:
 285ms
get tp. blocked users:
 1ms
others: 245ms
total:  824ms
созд. / загр.: 824ms
x
x
Закрыть


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