powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Прокачайте идею
19 сообщений из 19, страница 1 из 1
Прокачайте идею
    #35305714
Val_Kill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прошу прокачать следующую идею:

1. В базе данных все поля имеют уникальные имена.
2. Для нормального (по русски / по польски / ... ) отображения названия полей в интерфейсных формах отчетах запрашиваются значения из системных таблиц с описанием каждого поля.
3. На клиенте поле для ввода создается в зависимости от типа (varchar / integer / date ...)

Вроде выигрываем в отсутствии необходимости рисовать контролы для каждой таблицы.

Заранее благодарен.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35305814
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Val_Kill1. В базе данных все поля имеют уникальные имена.
2. Для нормального (по русски / по польски / ... ) отображения названия полей в интерфейсных формах отчетах запрашиваются значения из системных таблиц с описанием каждого поля.
3. На клиенте поле для ввода создается в зависимости от типа (varchar / integer / date ...)

Вроде выигрываем в отсутствии необходимости рисовать контролы для каждой таблицы.1. что будем делать когда некоторые поля не надо будет показывать в гриде?
2. Умные гриды сами так делают
3. Названия полей "по русски / по польски" в БД - крайне не рекомендуется.
4. Если для гридов такое может подойти, то формы рисовать, всетаки, придется.
Стандартными визардами (типа Access-овских) эргономичную форму не сделаешь.
5. Для простых форм их рисование много времени не занимает.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35306322
Val_Kill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely

1. что будем делать когда некоторые поля не надо будет показывать в гриде?
2. Умные гриды сами так делают
3. Названия полей "по русски / по польски" в БД - крайне не рекомендуется.
4. Если для гридов такое может подойти, то формы рисовать, всетаки, придется.
Стандартными визардами (типа Access-овских) эргономичную форму не сделаешь.
5. Для простых форм их рисование много времени не занимает.



1. - В принципе как и в форме так и в гриде можно списком инициализировать те поля которые показывать/не показывать.

2. - Поподробнее. если можно.
3. - Интересно это почему?
4. - Отчасти согласен. Если нужно что-то спецефичное.
5. - Все равно запаривает. Время жалко. А потом постоянное переименование полей на адекватные названия в отчетах.

Смущает еще такой факт, что у некоторых контролов есть свои обработчики определенных событий. Такие фичи абстрактно тяжело описать.

Интересно кто-то пробовал реализовывать такую концепцию в жизни. Насколько она работоспособна.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35306397
1. В скором будущем вылезет боком уникальность полей - типа id1, id2, id3, idn
2. В скором будущем вылезет боком универсальность - т.к. всё имеет тенденцию к мутированию и усложнению. Потому формы и гриды полюбэ будут усложнять ся в ручном режиме (смвсл автомата?)
3. В скором будущем вылезет боком желание переписать в нормальный вид.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35306793
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На мой взгляд, более жизнеспособны вариации такого подхода
Visual Grid Designer Dangers
...
Рейтинг: 0 / 0
Прокачайте идею
    #35306899
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Val_KillВ базе данных все поля имеют уникальные имена
Это малореально. Вернее, для мало-мальски серьезной базы станет крайне неудобным и приведет к появлению совершенно дефективных названий. Кроме того, это не нужно.

Val_Kill2. Для нормального (по русски / по польски / ... ) отображения названия полей в интерфейсных формах отчетах запрашиваются значения из системных таблиц с описанием каждого поля.
Это нормально, но в свете предыдущего, как мне кажется, Вы забыли об одной детали - поля в таблицах не всегда так же называются в запросах. Если Вам нужно вывести в грид результат самосоединения таблицы, как минимум одно из полей, хоть убей, придется переименовывать.

Val_Kill3. На клиенте поле для ввода создается в зависимости от типа (varchar / integer / date ...)
Скукота.

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

Никто не мешает Вам написать код, который в дизайн-тайме бросит на форму "заготовку" из тех самых "полей в зависимости от типа". Быть может я Вас удивлю, но если например в дельфе Вы откроете запрос и драгдропнете поля из него на форму - именно это и получите (если конечно фичу не отрубили... давно не проверял). А вот генерить каждый раз в рантайме - занятие для молодых людей, которым некуда девать оплаченное работодателем время.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35306995
Val_Kill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer
Это малореально. Вернее, для мало-мальски серьезной базы станет крайне неудобным и приведет к появлению совершенно дефективных названий. Кроме того, это не нужно.


Не согласен. если просто делать префикс - имя таблицы. ИМХО ничего дефектного в этом нет. хотя конечно зависит от имени таблицы.

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


этот агрумент пожалуй самый веский. Как вариант - хр.процедура и именовать выходные параметры.

softwarer
Скукота.


Я в общем понимаю что ничего крутого в этом нет.

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


Как раз из-за того что времени мало. Прокачиваю данную тему. Запарился я одни и теже названия в отчетах и формах писать ручками.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307054
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Val_KillНе согласен. если просто делать префикс - имя таблицы. ИМХО ничего дефектного в этом нет. хотя конечно зависит от имени таблицы.
Это зависит от всего. Грубо говоря, пока в базе пара сотен полей во всех таблицах вместе взятых - их можно сделать уникальными и нормально названными одновременно, но по мере роста очень быстро становится трудно. Когда таблиц несколько десятков, называть их коротко - в несколько букв - или использовать короткие префиксы уже не получится, вернее будет напоминать разговор на китайском. Когда у таблицы появляется собственный префикс..... я вот например не готов считать "недефективным" имя поля наподобие fin_movement_document_id_from.

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

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

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

Val_KillКак раз из-за того что времени мало. Прокачиваю данную тему. Запарился я одни и теже названия в отчетах и формах писать ручками.
Разделяйте темы. Насчет названий - нормально и правильно. Но с автогенерацией контролов это совершенно не связано.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307056
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если уж делать свой слой метаданных, то именами полей он не должен ограничиваться.

Метаданные - вещь неоднозначная, но она может дать существенные выигрыши в некоторых случаях.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307072
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Val_Kill..Вроде выигрываем в отсутствии необходимости рисовать контролы для каждой таблицы.....

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

минусы подхода - бОльше по времени тестирование такого подхода (перебор всех типов, связей и прочей лабуды)...
плюсы - при изменении БД, либо добавление "хочу видеть-искать-оперировать" поля - время на программирование-отладку не расходуется. Соответственно нервов и гимора меньше. Только на уровне прописать пару строк в системные таблицы и получаешь результат...


с уважением
(круглый)
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307331
мне нравитсо другая реализация этой идеи.

для всех технических и вспомогательных таблиц поле ID берётся из одного сиквенса (так называемая сквозная нумерация).
после чего создаётся вьюха например:

create view objects as
select uid id, 'USER' from user
union all
select gid id, 'GROUP' from group
union all
select rid id, 'RIGHT' from right
union all
select docid id, 'DOCUMENT' from document
....................


запрос типа
select * from objects where id=1234
всегда выдаст нужный ID илди даже имя таблицы. Сотря какая вьюха.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307415
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Подброшу еще один факт: одно и то же поле в разных случаях нужно называть по-разному. Скажем, чекбокс в форме ввода может называться "Является резидентом РФ", а тот же самый чекбокс в гриде будет озаглавлен "Рез." Кроме того, бывает, что одно и то же поле несет имеет разный смысл в зависимости, например, от типа записи.



Ха.

LABEL
COLUMN-LABEL

Тем не менее - не сторонник такого подхода. Точнее - только такого.
Еще точнее - все эти параметры должны автоматом (по умолчанию) подставляться именно в дизайн-тайме. Ну, а при необходимости, можно и подкрутить.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307420
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Николай1Ха.

LABEL
COLUMN-LABEL
И где ты их нашел в системных таблицах?
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307645
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer Николай1Ха.

LABEL
COLUMN-LABEL
И где ты их нашел в системных таблицах?

Ни Ораклом единым!

ADD FIELD "FieldName" OF "TableName"
TYPE "INTEGER"
LABEL "Длинное имя для формы"
COLUMN-LABEL "Кор. имя"
...
Рейтинг: 0 / 0
Прокачайте идею
    #35307647
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Николай1 softwarer Николай1Ха.

LABEL
COLUMN-LABEL
И где ты их нашел в системных таблицах?

Ни Ораклом единым!
Код: plaintext
1.
2.
3.
4.
ADD FIELD "FieldName" OF "TableName"
    TYPE "INTEGER"
    LABEL "Длинное имя для формы"
    COLUMN-LABEL "Кор. имя"


Пожалуй, все-таки "Не Ораклом".
...
Рейтинг: 0 / 0
Прокачайте идею
    #35309540
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зачем вам еще один браузер баз данных?
Кажется, DBU был первым.

А если между базой и визуальным интрфейсом есть хоть немного прикладной логики,
то что остается от идеи?
...
Рейтинг: 0 / 0
Прокачайте идею
    #35309640
Val_Kill
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ModelRЗачем вам еще один браузер баз данных?
Кажется, DBU был первым.

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

В любом случае проблему корректных имен полей можно решить таким способом а если еще и получитьсё что-то автоматизировать то почему НЕТ?

Кстати DBU это что?
Утилита для работы с базами 1С:Бухгалтерия 6.0 ? (google выдал)
...
Рейтинг: 0 / 0
Прокачайте идею
    #35310711
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Val_Kill
Кстати DBU это что?
Утилита для работы с базами 1С:Бухгалтерия 6.0 ? (google выдал)
ДОСовская система программирования Clipper имела эту штуку в своем составе.
1С использует .dbf формат, так что DBU и для этого годилась.
...
Рейтинг: 0 / 0
Прокачайте идею
    #35312396
_Kostyan_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Хм вот была та же идея, но понял, что т.к. система имеет свойство к усложнению, то и метаданных об "архитектуре клиента" надо все больше и больше.

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

Хотя тянуть ПК - ФК, АК и чеки - почему бы и нет, если они 1 раз в базе прописаны - можно и воспользоватся, т.б. зачем в дальнейшем при возможных изменениях их актуализировать?

опять-же вопрос 3-й, а если много логики на триггерах, их тянуть - и разбирать - работы много... в общем для "общего случая" - идея не подходит, а вот если на систему (ни в коем случае не искуственно !!) наложен ряд ограничений - тогда пожалуйста.
...
Рейтинг: 0 / 0
19 сообщений из 19, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Прокачайте идею
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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