Dataset - что даёт определение полей?

[DeveloPerchik]

Dataset - даёт ли что-то точное указание (создание, название, указание типа, итп) всех полей Dataset? ведь и без указания Dataset запрашивает все поля у БД. Есть ли разница?

[Аватар]

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

[DeveloPerchik]

с другой стороны удобно обращаться к фиелдам без FieldByName,

Какая разница Dataset.FieldByName('NUMBER').Value или dfNUMBER.Value? типа букв меньше?

в гриды вставлять явное описание,

Не понял. Без объявления полей на Dataset нажал-отжал Active и все настройки полей Grid'ом восприняты.

калькулируемые поля использовать.

Это понятно. Вопрос про пассивные поля - нужно ли их описывать в каждом Dataset?

[Аватар]

типа букв меньше?

Не только, еще минимизирует возможность ошибки, которая для FieldByName только во время выполнения обнаружится

Без объявления полей на Dataset нажал-отжал Active и все настройки полей Grid'ом восприняты

Если только все поля и в той же последовательности. И поработайте с гридами, в которых динамически изменяется отображаемость колонок, положение, размеры, титулы и фоттеры (в DbGridEh например), состояние которых нужно запомнить при Close формы, чтобы при следующем входе восстановить

[DeveloPerchik]

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

[Stilet]

минимизирует возможность ошибки

Как сказать... А если эти поля прописаны в INI файле, т.е. датасет у меня настраиваемый извне? Тогда описывать переменную-поле нельзя.
ИМХО - не люблю описывать жестко поля в переменные, мне проще использовать FieldByName

[Аватар]

Важных доводов "за" не услышал.

А их и нет. Каждый пользуйтся тем и так, как ему удобней и как диктуют условия поставленной задачи. И именованный фиелд ничем не отличается от фиелда возвращенного методом FieldByName, достаточно в отладке посмотреть, чтобы убедиться, что это один и тот же объект, просто сравнив например ADOQuery1.FieldByName('Tip') и ADOQuery1Tip

Тогда описывать переменную-поле нельзя

Почему? Я тоже в ini сохраняю настройки гридов и не зависимо от способа работы с фиелдами туда сохраняю просто имена полей

[Stilet]

Тогда 1:1
Действительно тут все зависит от вкусов разработчика

[Аватар]

Могу добавить еще, что FieldByName ищет заданное поле просто перебором в массиве полей и возвращает тип TField, а именованный фиелд это ссылка на фиелд в том же массиве (замечу - нет ни какого цикла поиска, это +), но тип уже привязан к конкретному типу поля (TIntegerField, TDateTimeField и пр., тоже +), что дает определенные удобства при работе с ним. Само собой именованные фиелды не пригодны для работы с датасетами, у которых список полей может изменяться

[DeveloPerchik]

Сообщение от Аватар

Могу добавить еще, что FieldByName ищет заданное поле просто перебором в массиве полей и возвращает тип TField, а именованный фиелд это ссылка на фиелд в том же массиве (замечу - нет ни какого цикла поиска, это +), но тип уже привязан к конкретному типу поля (TIntegerField, TDateTimeField и пр., тоже +)

А по скорости это что-то даёт? Или определение полей в кол-ве до 50шт это ерундовая незаметная задержка?

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