DBGrid

← →
Галинка (2008-06-24 16:07) [40]

Sergey13 © (24.06.08 16:02) [39]

самое инетерсное, что не только борланд, но и мелкие тоже таскают. Но формы как-то конкретнее что ли. Незря же в том же аксесе мона формы свои дизайнить. Да и Oracle Forms.

← →
Sergey13 © (2008-06-24 16:27) [41]

> [40] Галинка (24.06.08 16:07)

Так табличное представление данных более всего соответствует табличным данным, которые собственно и лежат в реляционной БД.
ИМХО.

← →
Ega23 © (2008-06-24 16:29) [42]

> Так табличное представление данных более всего соответствует
> табличным данным, которые собственно и лежат в реляционной
> БД.

Только таблицы ещё имеют особенность связываться друг-с-другом...

← →
Галинка (2008-06-24 16:40) [43]

Sergey13 © (24.06.08 16:27) [41]

так базы потому и реляционные. Да и не всегда в таблице данные разаны явно. Пример все с теми же заказами. Получаем одну форму. А в ней данные клиента (Customer), данные заказа (Order), данные товара (Goods, GoodGroup), данные доставки (Schipping), данные доставщика (SchippingFirm). Таблица заказ будет как-бы главная (относительно), и большая часть полей в ней будет связана по ID с остальными таблицами. Для того и есть нормализация. Или? Как и зачем все это в грид один затащить?

← →
Галинка (2008-06-24 16:45) [44]

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

Собственно ИМХО для этого макросы в экселе и в акцесе и ввели. Потому что не все можно в таблице показать.

← →
Ega23 © (2008-06-24 16:47) [45]

> Галинка (24.06.08 16:45) [44]

Давай, дави его!
Мы с ним уже года 4 насчёт редактирования в гриде бодаемся. Если не все 5. :)))

← →
Sergey13 © (2008-06-24 16:48) [46]

> [42] Ega23 © (24.06.08 16:29)

Ну и что? Запрос на объединение этих данных имеет все равно вид плоской таблицы (почти всегда).

> [43] Галинка (24.06.08 16:40)
Никто и не предлагает редактировать ВСЮ БД в одном гриде. А вот какую нибудь конкретную накладную, данные для которой взяты с учетом указанных тобой связей - почему нет?

Я не призываю редактировать ТОЛЬКО в гриде. Я изначально высказал сомнение лишь в том, что такое редактирование следует огульно считать "мове тоном".

← →
Sergey13 © (2008-06-24 16:50) [47]

> [45] Ega23 © (24.06.08 16:47)

Эту песню не задушишь не убьешь, не убьешь, не убьешь! (с) пестня советских композиторов.
8-)

← →
Галинка (2008-06-24 16:52) [48]

Ega23 © (24.06.08 16:47) [45]

да меня тоже помню задавили ))) Просто за деревьями иногда леса не видно ))

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

← →
MsGuns © (2008-06-24 16:54) [49]

>Sergey13 © (24.06.08 16:02) [39]
>ИМХО все-таки наверное не зря Борланд таскает свой грид из версии в версию. Да еще и сторонние разработчики соревнуются в написании своих гридов, причем очень даже недешевых порой.

Чисто маркетинговый ход. Без "сеточной" корректировки масса программистов откажутся от компонентов

>Да и в том же мелкомягком аксесе, если мне не изменяет память, грид так-же присутствует.

А ты пробовал менять в сетках запросные данные, вытащенные из нескольких таблиц ? Рекомендую попробовать и ты увидишь как мелкомягкие решают проблемы "универсальности" ;)

Я уже много раз повторял, что редактирование в сетке без ПОНИМАНИЯ механизма - штука очень опасная и вредная. Но кто услышит глас одинокого ?

← →
Sergey13 © (2008-06-24 17:00) [50]

> [49] MsGuns © (24.06.08 16:54)
> без ПОНИМАНИЯ

Без понимания и кирпич - оружие пролетариата. 8-)

← →
Галинка (2008-06-24 17:01) [51]

Sergey13 © (24.06.08 16:48) [46]

так в том то и дело, что это все содержит ОДНА КОНКРЕТНАЯ НАКЛАДНАЯ. Или можно выкинуть хоть что-то из нее?

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

Короче, забрели мы в темный лес. И опять холивар начался (((

← →
Галинка (2008-06-24 17:04) [52]

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

← →
stas © (2008-06-24 17:10) [53]

Галинка (24.06.08 17:04) [52]

В некоторых случаях для редактирования тоже.
Я допустим где нужно делаю так:
в ADO включаю locktype в bathoptimistic.
Пользователь меняет в гриде данные, а на afterpost ado компонента
срабатывает сохранение данных с помощью хранимки.

← →
korneley © (2008-06-24 17:12) [54]

> Галинка (24.06.08 17:04) [52]

Дык, и я о том же. Грид удобен для визуализации, в первую очередь - "компактностью" - одна строка = одна сущность (блин, как Беренджер заговорил :) Но для редакции? Только если связей нет, иначе - форма. Да и оконечному юзеру есть шанс на внятные кнопочки посмотреть и о смысле набитого подумать :) И за нажатие "Ok" он уже не, "типа, отвечает", а "отвечает конкретно".

← →
Галинка (2008-06-24 17:22) [55]

stas © (24.06.08 17:10) [53]

ты наверное удивишься, но я в курсе. У меня даже в проекте как-то было редактирование в гриде. А в последнем было даже редактирование массива (спасибо Игорю, научил, как оно в дотнете пашет). Но для сохранения все же лучше отдельный орган управления поставить (причем с эффектом типа, пока данные не поменялись Enable:=false; если есть что сохранить, тогда активно. И для совсем клинического случая переж закрытием формы спросить для надежности, сохранять или как?). Тогда будет точно понятно, что уже отредактировано и сохранено.

← →
stas © (2008-06-24 17:31) [56]

Галинка (24.06.08 17:22) [55]

Ну это уже мелочи, главное сам факт редактирование в гриде

← →
Sergey13 © (2008-06-25 09:11) [57]

> [51] Галинка (24.06.08 17:01)

> так в том то и дело, что это все содержит ОДНА КОНКРЕТНАЯ НАКЛАДНАЯ.
Накладная - это сложный документ, который обычно состоит из шапочной и табличной частей. Что мешает редактировать табличную в гриде? При чем не всегда при этом затрагиваются поля связи. Например ввод каких нибудь продажных цен рядом с ценой поставки.

> Но промышленные базы такое позволяют редко.

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

> Если база нормирована, в ее таблицах не так много полей.

А "не так много" - это сколько? И как это влияет?

> Тогда грид будет скорее всего аггрегатным.
Это предположение, возможно основанное на личном опыте. Но опыт у всех разный.

> [54] korneley © (24.06.08 17:12)
> Да и оконечному юзеру есть шанс на внятные кнопочки посмотреть
> и о смысле набитого подумать :)

Грид и "внятные кнопочки" - это отнють не противопоставление.

← →
Галинка (2008-06-25 09:48) [58]

Sergey13 © (25.06.08 09:11) [57]

согласна... В споре таки родилась истина. )))

ПыСы: промышленная база - это нормированная база, а не рееств видеозаписей в домашней видеотеке. Как пример была приведена база каталожной фирмы (Customer, Orders, Order, Goods, GoodsGroup, Schiping, SchippingFirm, CreditNotes и т.д.) Там будет максимум до десяти (а скорее до восьми) полей на таблицу, причем бОльшая часть будет полями связи.

← →
Sergey13 © (2008-06-25 09:53) [59]

> [58] Галинка (25.06.08 09:48)
> ПыСы: промышленная база - это нормированная база

Все-таки наверное нормализованная, а не нормированная?

← →
Галинка (2008-06-25 09:54) [60]

точно... склероз...

← →
MsGuns © (2008-06-25 10:00) [61]

Встану на сторону тезки. Иногда сетка при редактировании не просто желательна - ОБЯЗАТЕЛЬНА. Например при массовых "вбитиях" данных - у нас вот сейчас вводят лицевые зарплаты за период с 91-го по 99 (Ленты ЕС-вские в свое время не позаботились скопировать на другие носители, козлы !). Миллионы документо-строк ! Как там без "сетки" и "Эксельной" технологии ?
Но я это реализовал клиентскими датасетами - и все на ура пляшет. А если б делал "как обычно" - получил бы тучу траблов

← →
Галинка (2008-06-25 10:13) [62]

MsGuns © (25.06.08 10:00) [61]

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

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

← →
Sergey13 © (2008-06-25 10:15) [63]

> [60] Галинка (25.06.08 09:54)

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

> Как пример была приведена база каталожной фирмы

А я вот сейчас глянул в нашу биллинговую базу (более 100000 абонов, более 1000000 соединений в день) и обнаружил там таблицы (не самые второстепенные) с количеством полей под 50. Это не промышленная база?

← →
Anatoly Podgoretsky © (2008-06-25 11:01) [64]

> MsGuns (25.06.2008 10:00:01) [61]

Ну массовый ввод это понятно, а сетка для чего.

← →
Anatoly Podgoretsky © (2008-06-25 11:02) [65]

> Sergey13 (25.06.2008 10:15:03) [63]

Количество полей не самоцель.

← →
Sergey13 © (2008-06-25 11:03) [66]

> [65] Anatoly Podgoretsky © (25.06.08 11:02)

Так и я про то.

← →
Галинка (2008-06-25 11:23) [67]

Sergey13 © (25.06.08 10:15) [63]

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

← →
Sergey13 © (2008-06-25 12:06) [68]

> [67] Галинка (25.06.08 11:23)
> интересно, их все надо постоянно видеть?

Постоянно никто их все и не смотрит. Этот пример я привел по поводу "промышленных БД". Типа разные они бывают.

>Anatoly Podgoretsky © (25.06.08 11:01) [64]
>Ну массовый ввод это понятно, а сетка для чего.

Как ты предложишь вводить лицевые зпл без сетки ?

> MsGuns (25.06.2008 16:04:09) [69]

Предлагаю вводить в форме.

> Предлагаю вводить в форме.

Отдельная модальная форма на редактирование сущности плоха только в одном единственном случае - скоростной ввод данных. Когда пользуешься только клавой, про мышку вообще забываешь, и т.п. Горячие клавиши - в конкретном данном случае вещь неудобная.

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

Другое дело, что я массу геморроев обрёл на Update-ах и т.п. Но это уже к делу не относится... :)

> Ega23 (25.06.2008 17:11:11) [71]

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

← →
Галинка (2008-06-25 19:45) [73]

Ega23 © (25.06.08 17:11) [71]

а при чем горячие клавиши? TabIndex уже отменили? И это лишь самый простой способ.

Анатолий, а автопереход по нажатию на Enter? Очень интеерсный приемчик, надо где-то запомнить.

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

>Anatoly Podgoretsky © (25.06.08 17:25) [72]
>Отдельная модальная форма никак не мешает скоростному вводу данных

Мешает. Например удобно сначала ввести ВСЕ колонки месяц, год, вид оплат, а потом сверху вниз собственно суммы

> Галинка (25.06.2008 19:45:13) [73]

Имелся в вилу автопереход не по Enter, а по заполнению поля, например поля из четырех символов, после ввода четвертого символа автопереход на следующее поле, это из dBase/FoxPro (там это управляемое поведение). Автозаполнение по шаблону тоже имеется, а шаблоном является текущая запись, операторы это используют. В итоге в форме ввод быстрее и с меньшим процентом ошибок. По заполнению одной формы переход на заполнение следующей и так пока не будет отменено.
Формы часто имею следующий формат - вверху форма, внизу грид. На гриде можно перейти на изменение или удалить строку, а ввод/изменение в верхней части.
Сообственно этот формат у авторов последовательно мигрировал из ДОС (ФоксПро) в Windows (ФоксПро) и сейчас в Visual Basic (насколько я понял). Программа полностью покрывает потребности нашей фирмы по учету. В ней не было только отдела кадров, но эту часть я сам написал, благо в структуру все было заложено.

> MsGuns (25.06.2008 19:47:14) [74]

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

← →
Галинка (2008-06-25 20:14) [77]

Anatoly Podgoretsky © (25.06.08 20:07) [75]

ага. У нас на фирме примерно так же (программа для учета рабочего времени). Я теперь вспомнила. Т.е. вводишь дату. Она и так MaskEdit, так как только последнюю цифру ввел, курсор сам перескочил. А в гриде только видно, что уже ввел. Если где-то ошибка, то удалили и ввел заново.

MsGuns © (25.06.08 19:47) [74]

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

← →
Галинка (2008-06-25 20:16) [78]

офф:

смотрю на наши обсуждения и в голове крутится "Психбольница в руках пациентов".

> а при чем горячие клавиши? TabIndex уже отменили? И это
> лишь самый простой способ.

А я не про перемещение в рамках модальной формы. TabOrder - это второе, что я делаю после выстраивания всех контролов.

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

> Галинка (25.06.2008 20:14:17) [77]

В Экселе переход управляемый.

DBGrid Найти похожие ветки