Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

DBGrid [D7, XP]

Страницы: < 1 2 3 4 5 >
AlekseyB © (2008-06-24 08:59:00)
Подскажите плиз. Есть грид, где отображаются данные, необходимо в грид вносить данные и чтобы они сохранялись. Когда меняю несколько записей то сохраняет нормально, хотя не всегда, а если одну запись меняю, то совсем не сохраняет. Не подскажите в чем проблема ?

Anatoly Podgoretsky (2008-06-25 16:56:00) [21]
> MsGuns (25.06.2008 16:04:09) [69]

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

MsGuns (2008-06-25 16:04:00) [22]
>Anatoly Podgoretsky © (25.06.08 11:01) [64]
>Ну массовый ввод это понятно, а сетка для чего.

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

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

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

Галинка (2008-06-25 11:23:00) [24]
Sergey13 © (25.06.08 10:15) [63]

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

Sergey13 (2008-06-25 11:03:00) [25]
> [65] Anatoly Podgoretsky © (25.06.08 11:02)

Так и я про то.

Anatoly Podgoretsky (2008-06-25 11:02:00) [26]
> Sergey13 (25.06.2008 10:15:03) [63]

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

Anatoly Podgoretsky (2008-06-25 11:01:00) [27]
> MsGuns (25.06.2008 10:00:01) [61]

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

Sergey13 (2008-06-25 10:15:00) [28]
> [60] Галинка (25.06.08 09:54)

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

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

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

Галинка (2008-06-25 10:13:00) [29]
MsGuns © (25.06.08 10:00) [61]

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

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

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

Галинка (2008-06-25 09:54:00) [31]
точно... склероз...

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

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

Галинка (2008-06-25 09:48:00) [33]
Sergey13 © (25.06.08 09:11) [57]

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

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

Sergey13 (2008-06-25 09:11:00) [34]
> [51] Галинка (24.06.08 17:01)

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

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

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

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

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

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

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

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

stas (2008-06-24 17:31:00) [35]
Галинка (24.06.08 17:22) [55]

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

Галинка (2008-06-24 17:22:00) [36]
stas © (24.06.08 17:10) [53]

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

korneley (2008-06-24 17:12:00) [37]

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

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

stas (2008-06-24 17:10:00) [38]
Галинка (24.06.08 17:04) [52]

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

Галинка (2008-06-24 17:04:00) [39]
вобщем грид удобен больше для просмотра результатов, чем для редактирования.

Галинка (2008-06-24 17:01:00) [40]
Sergey13 © (24.06.08 16:48) [46]

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

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

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

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »