|
|
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher >>> Пользователь сможет, свободно скрывать, добавлять, менять местами поля, в том числе, разумеется, и те, которые, которые выбраны разработчиком, как поля по умолчанию. Эти манипуляции с полями происходят на уровне GUI, а из таблиц "тянется" всё. Зачем тянуть все? Порочный принцип. Если пользователю нужно быстро выбрать человека по ФИО, а в базе хранятся еще и фотки, то Вы фотки тоже будете тянуть и не показывать? Когда я писал ВСЕ, я имел ввиду: все, доступные для пользовательского выбора. GUI я вижу, как таблицу с возможностью сортировки, группировки, поиска и фильтрации. Фотография в такой таблице, находится не обязана. Можно нажать кнопку в GUI и увидеть фото. Но такой подход тоже не однозначен. Представьте таблицу, под которой находится форма с подробностями для каждой записи, вот там и может быть фотография. Пользователь скроллирует записи, а внизу меняются фотографии. При таком подходе фотографию нужно "тянуть" всегда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 14:09 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
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(); Для метаданных в виде таблиц - добавить для таблицы "выборки" связанную таблицу "Вычисляемые поля" с полями "Выражение" и "Алиас". Или о чем мы вообще говорим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 14:14 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
kordaПредставьте таблицу, под которой находится форма с подробностями для каждой записи, вот там и может быть фотография. Пользователь скроллирует записи, а внизу меняются фотографии. При таком подходе фотографию нужно "тянуть" всегда. Думаю, мы плавно подходим к мысли о необходимости как минимум двух видов форм: для просмотра всей (или почти всей) информации в таблице, и для быстрого выбора из таблицы как из справочника по двум-трем полям. Глубина открытия потрясает :-) Вообще, я еще раз советую Вам: возьмите какую-нибудь большую программу, интерфейс которой Вам нравится. Проанализируйте типы форм, которые там встречаются. И составьте список фич, которые нужны для полного счастья. А потом уже думайте над автоматизацией рутины. Потому что просто автоматический просмотрщик таблиц, как он у Вас наклевывается, по одной форме на таблицу, будет дубов, неудобен, и вряд ли кому-то нужен; а по сравнению с классическим подходом - еще и страшно труднорасширяем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 14:26 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
2 Cane Cat Fisher В чем принципиальная разница между Вашим и моим примерами? В том, что у Вас описание поля и описание выражения никак не связаны. Выражение, для Вас - это лишь некий набор символов. Давайте сделаем так будто, при написании Вашего примера, Вы сделали описку, написав в одном месте в качестве имени таблицы MAN, а в другом - MEN Код: plaintext 1. 2. 3. 4. 5. 6. Такая ошибка вылезет только в рантайм, и хорошо, если вылезет, так как вполне может быть, что таблица MEN существует! Теперь, посмотрите у меня. Символичесое имя (CITY)задано лишь один раз, а дальше лишь программные ссылки на переменную: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 14:40 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Так... Я вижу, что постепенно втягиваюсь в проект, который реально мне не под силу. Т.е. теоретически, видимо, я смогу сделать, то, что мне требуется, но программа получится сложной и некрасивой, метаданные - уродливыми. И через какое-то время я сам не смогу с ней разобраться. Это то, что случится реально. О чем, вобщем-то, многие предупреждали ( Bely и др.). Помимо этого, Cane Cat Fisher справедливо писал о расширении власти декларативного ядра за счет сужения функций кода, отвечающего за бизнес логику. Да и во мне было какое-то чувство страха перед этим. Но проблема существует! Я вот подумал, может быть вместо ядра нужен простой набор утилит, помогающих выполнять так сказать черную работу ? Такие утилиты особо не ограничат свободу, так как использование их не будет необходимым. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 15:22 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
kordaТакая ошибка вылезет только в рантайм, и хорошо, если вылезет, так как вполне может быть, что таблица MEN существует! Когда все пишут SQL-запросы вручную, то находятся именно в этой же ситуации. И ничего, живут. А в метаданных можно с тем же успехом описАться: Код: plaintext 1. kordaможет быть вместо ядра нужен простой набор утилит, помогающих выполнять так сказать черную работу? Для начала сформулируйте, что такое "черная работа" на разных этапах разработки и сопровождения, и сколько процентов времени она отнимает? А какая работа является "белой"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 16:11 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher kordaТакая ошибка вылезет только в рантайм, и хорошо, если вылезет, так как вполне может быть, что таблица MEN существует! Когда все пишут SQL-запросы вручную, то находятся именно в этой же ситуации. И ничего, живут. А в метаданных можно с тем же успехом описАться: Код: plaintext 1. Разница принципиальная, описка, в приведенном Вами примере - это описка в имени переменной, следовательно выявится уже на этапе компиляции. Cane Cat Fisher Когда все пишут SQL-запросы вручную, то находятся именно в этой же ситуации. И ничего, живут. Плохо живут... Невозможно отладить SQL без того, чтобы присоединиться к БД. Ну, конечно, этому есть свои причины. SQL - не язык программирования. Я слышал о нескольких проектах (увы, не помню названий), цель которых сделать языковую оболочку над SQL, приравняв тем самым написание запросов и программирование бизнес-логики. Необходимо отметить, что проекты эти пока в зачаточном состоянии. Cane Cat Fisher Для начала сформулируйте, что такое "черная работа" на разных этапах разработки и сопровождения, и сколько процентов времени она отнимает? А какая работа является "белой"? Может быть это не очень точное определение, но черная работа - это та работа, которую можно автоматизировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 17:15 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
korda Разница принципиальная, описка, в приведенном Вами примере - это описка в имени переменной, следовательно выявится уже на этапе компиляции. Если вернуться к Вашему предположению, что таблица MEN существует, то и переменная m E nColumn может существовать. И компиляция пройдет успешно. kordaНевозможно отладить SQL без того, чтобы присоединиться к БД. Точно так же можно поплакаться, что программный код невозможно отладить без пробной компиляции. Я, например, не вижу здесь проблемы. Если мне нужно использовать сравнительно сложный SQL-запрос, я сначала набираю его в текстовом файле (FAR, знаете ли, приятная штука), запускаю на исполнение через SQL-консоль много раз, и отлаживаю до полного счастья, отлавливая синтаксис, а заодно посмотрев план. Изменил - перезапустил - смотрю результат - доли секунды. И только потом подкладываю этот файл в папку sqlfiles, откуда от попадает в ресурсы программы. А потом ресурсную строку использую где надо. kordaМожет быть это не очень точное определение, но черная работа - это та работа, которую можно автоматизировать. Хм. В данном случае работу автоматизировать несомненно можно, но усилия на это многократно превысят саму работу за несколько месяцев, плюс есть подозрение, что автоматизация никак не покроет все разновидности этой работы, зато заметно усложнит дальнейшую работу за счет непонятного взаимодействия недоавтоматизированной работы с самой ее автоматизацией. Вот. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2008, 17:48 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher Я, например, не вижу здесь проблемы. Если мне нужно использовать сравнительно сложный SQL-запрос, я сначала набираю его в текстовом файле (FAR, знаете ли, приятная штука), запускаю на исполнение через SQL-консоль много раз, и отлаживаю до полного счастья, отлавливая синтаксис, а заодно посмотрев план. Изменил - перезапустил - смотрю результат - доли секунды. И только потом подкладываю этот файл в папку sqlfiles, откуда от попадает в ресурсы программы. А потом ресурсную строку использую где надо. А я вижу здесь проблему... Описанная методика (набирать запросы в текстовом редакторе) ничем не отличается от того, как работали четверть века назад. Никакой проверки синтаксиса, существования объектов и прочего... Неужели с тех лет ничего не изменилось? Я не в курсе. FAR мне тоже нравится. Но неужели ничего не изменилось с тех лет в плане проектирования запросов? Вне связи с вышесказанным, я тут "нарыл" один проект, который в каком-то смысле близок к моей цели: Squiggle SQL Builder for Java Конечно, доверия к нему - никакого, слишком малоизвестный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2008, 22:30 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
kordaОписанная методика (набирать запросы в текстовом редакторе) ничем не отличается от того, как работали четверть века назад. Никакой проверки синтаксиса, существования объектов и прочего... Неужели с тех лет ничего не изменилось? Я не в курсе. FAR мне тоже нравится. Но неужели ничего не изменилось с тех лет в плане проектирования запросов?Уже столько лет прошло с изобретения компьютера, а програмисты все пишут и пишут программы... странно, почему еще никто не заменил програмистов А что касается запросов - то эти запросы со временем становятся все более изощреннее, требования пользователей все более извращеннее. Поэтому проще спеца обучить SQL, чем разбирать что наконструирует непонимающий пользователь. PS: а для отладки и написания запросов есть более удобные тулзы, нежели простой NOTEPAD. Есть и графические конструкторы запросов, но они СИЛЬНО УБОГИЕ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2008, 00:46 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Обнаружил родственную тему на этом же форуме: Как сделать конструктор селектов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2008, 02:05 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Кажется, приближаюсь к цели! Что поддерживается на сегодняшний день: - Множественные ссылки на одну и ту же таблицу, в том числе и на саму себя. - Вычисляемые поля. - Возможность выбора желаемых полей результата. - Возможность указания алиаса для любого из полей. - Автоматический алиасинг для присоединяемых таблиц. Извиняюсь, за неудобочитаемый пример, со временем постараюсь это исправить. Принцип следующий: Конструируем JoinBuilder , затем конфигурируем его, в соответствии с условиями задачи и запускаем построение запроса, передав построителю имя для вновь созданного VIEW . См. примеры. Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 02:17 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Я делал похожую задачу, правда с одним уровнем. Но думаю уровни нарастить не проблема. как можно сделать в вашем случае. 1. Все метаданные берутся из системных таблиц. Там хранятся первичные и вторичные ключи, наименование полей, таблиц, индексы(если надо будет проверить на производительность) и куча всего. Единственная проблема это наименование столбцов на Русском языке. Можно было использовать поле description, которое указывается для полей. А можно завести таблицу в которой для поля конкретной таблицы есть имя. Я пошел по второму пути, т.к. у меня 2 языка. Код: plaintext 1. 2. 3. 4. 5. 2. пользователь указывает таблицу которую он хочет посмотреть. Мы выполняем такой запрос: Код: plaintext 1. 2. 3. 4. По этим данным я думаю не будет стоит труда составить запрос с 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. p.s. запросы для DB2 но думаю любой БД можно найти аналоги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 09:38 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Да еще забыл сказать по уровни, уровни это глубина запроса, т.е. количество рекурсии. Это для того чтобы можно было указывать на сколько подробно пользователь хочет получить данные. + от циклического зависания, на иерархических таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 09:41 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
kordaОписанная методика (набирать запросы в текстовом редакторе) ничем не отличается от того, как работали четверть века назад. Никакой проверки синтаксиса, существования объектов и прочего... Как это никакой проверки синтаксиса? Запустите SQL-запрос, и получите полный диагноз по синтаксису и существованию объектов. Такое ощущение, что для соединения с БД Вам в другой конец города ехать. Честное слово, я перестаю понимать проблему, которую Вы решаете. kordaJoinBuilder builder0 = new JoinBuilder(Tables.WORKPLACE2.name()); А Вас не смущает, что для "автоматизации запроса" приходится набирать больше символов, нежели в самом запросе? Причем, IMHO, куда менее удобочитаемых и черезполгодасопровождаемых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 10:38 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Cane Cat FisherА Вас не смущает, что для "автоматизации запроса" приходится набирать больше символов, нежели в самом запросе? Причем, IMHO, куда менее удобочитаемых и черезполгодасопровождаемых.+1 !!! Я об этом писал ранее авторЧто касается инструмента, который будет создавать SQL запросы - время потраченное на составление схемы данных для такого инструмента будет сопоставимо со временем потраченным на написание самих SQL запросов. Оно вам надо - делать то же самое, но через задний проход? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 11:48 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher Как это никакой проверки синтаксиса? Запустите SQL-запрос, и получите полный диагноз по синтаксису и существованию объектов. Такое ощущение, что для соединения с БД Вам в другой конец города ехать. Ну, именно так и писали много лет назад. Набирали текст программы в текстовом редакторе, потом запускали компиляцию, находили номера стро с ошибками в листинге компилятора, затем снова шли в текстовый редактор и исправляли ошибки. А подсветка синтаксиса? А отлавливание синтаксических ошибок по мере набора? А подсказки во время набора? А удобная работа по сравнению версий? А проверка орфографии в комментариях? Я сам поначалу, принципиально, отказывался от всяческих средств разработки и пользовался простейшим текстовым редактором. Потом понял, что мне будет удобнее пользоваться специальными инструментами. Хотя, конечно, это дело весьма субъективное, - одному нравится одно, другому - другое, ведь в каждом подходе есть что-то свое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 12:20 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher А Вас не смущает, что для "автоматизации запроса" приходится набирать больше символов, нежели в самом запросе? Причем, IMHO, куда менее удобочитаемых и черезполгодасопровождаемых. Смущает, конечно... Пытаюсь объективно оценить приемущества и недостатки. Недостатки: - много набирать; - SQL - стандарт, а билдер - моя личная поделка, знакомая лишь мне одному; - выполняет генерацию запросов только одного типа; - текст запросов генерируется, а не содержится в файле ресурсов, что не способствует пониманию системы третьими лицами. Достоинства: - Нет проблем с синтаксисом, - всегда генерируется синтаксически правильный запрос; - Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте); - Нет проблем со случайным(по ошибке) пересечением имен полей и таблиц, уникальность поддерживается средствами языка. Что перевешивает? Пока не знаю... Может быть есть ещё какие-то достоинства и недостатки, которые я упустил? P.S. У меня нет цели что-либо утвердить подобным решением и у меня нет увереннсти, что оно лучше стандартного подхода, я лишь взвешиваю возможность применения данного подхода в определенных случаях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 12:39 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
olzhas 1. Все метаданные берутся из системных таблиц. Идя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 12:45 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
korda- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);В работающей системе переименовывать таблицу вобще не стоит. Даже если она названа с орфографическими ошибками. Потому что кроме вашей системы данными могут пользоваться ддругие системы, код хранимых процедур в БД. А на стадии проектирования - все переименования идут на этапе проектирования структуры БД, а не в момент написания кода. Кроме этого - простая смена имени таблицы легко решается с помощью Search Replace по метаданным или по текстам запросов. Да - это никто не любит делать, но это отнимает не так много времени как все говорят. Так что выгода от этого - почти неуловимая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 12:53 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
kordaolzhas 1. Все метаданные берутся из системных таблиц. Идя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно.Волков бояться - в лес не ходить. Можно метаданные брать не постоянно из системных таблиц, а закачать их один раз и далее их дорабатывать. Для этого вам надо написать 2-3 модуля доступа к словарям основных БД и конвертирования данных БД в ваши метаданные. После этого - можно достругивать данные вручную. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 12:58 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
olzhas Единственная проблема это наименование столбцов на Русском языке. Можно было использовать поле description, которое указывается для полей. А можно завести таблицу в которой для поля конкретной таблицы есть имя. Я пошел по второму пути, т.к. у меня 2 языка. Поле description, к сожалению, поддерживается далеко не всеми БД. И да, Вы правы, оно мало помогает, когда количество языков более одного. Ваш второй подход поддерживает любое количетсво языков, но не кажется ли Вам, что тексты, - часть пользовательского интерфейса, а не базы данных? Например, чтобы обеспечить моему переводчику возможность исправлять орфографию, я должен предоставлять ему соединение с БД? Я храню все тексты в файлах ресурсов. Кроме текстов, есть ещё иконки, звуки и прочее, что тоже является объектом локализации. Например, при входе в русскоязычную, программу проигрывается слово Привет, а в англоязычную поется - Hello. Читал где-то, что вид почтового ящика российского типа не приемлем в США и наоборот, так как их внешний вид совершенно различен. Таких примеров может быть множество. Только вчера видел english-версию одной программы, где на иконке кнопки сортировки были русские буквы "А" и "Я", как эта иконка "поможет" человеку, не знающему русский, понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 13:02 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Belykorda- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);В работающей системе переименовывать таблицу вобще не стоит. Даже если она названа с орфографическими ошибками. Потому что кроме вашей системы данными могут пользоваться ддругие системы, код хранимых процедур в БД. А на стадии проектирования - все переименования идут на этапе проектирования структуры БД, а не в момент написания кода. Я согласен. Имел ввиду именно - на стадии проектирования. Bely Кроме этого - простая смена имени таблицы легко решается с помощью Search Replace по метаданным или по текстам запросов. Да - это никто не любит делать, но это отнимает не так много времени как все говорят. Search/Replace довльно опасен, нет?... MY_KILLER_CUSTOMER_TABLE, MY_KILLER_CUSTOMER_COLUMN MY_KILLER_CUSTOMER_COLUMN переименовать в MY_CUSTOMER_COLUMN - здесь легко ошибиться и переименовть также и таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 13:13 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
kordaИдя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно. Хранить это в другом виде ещё более накладно. Где гарантия того что ваше хранилище метаданных будет соответствовать действительности. А соединение, как получать данные без соединения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 13:14 |
|
||
|
Оперативный файл и справочники. Автоматизация запросов.
|
|||
|---|---|---|---|
|
#18+
Belykordaolzhas 1. Все метаданные берутся из системных таблиц. Идя с системными таблицами хороша, но в этом подходе меня смущает то, что нужно знать имена и структуру этих таблиц, что является специфичным для каждой БД. Кроме этого, для чтения из системных таблиц необходимо наличие соединения с БД, что не всегда удобно. Можно метаданные брать не постоянно из системных таблиц, а закачать их один раз и далее их дорабатывать. Все равно метаданные поступают в БД из программы, так лучше, пусть уж там[в программе] и остаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2008, 13:19 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35589143&tid=1543584]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
173ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 480ms |

| 0 / 0 |
