Зачем были созданы новые типы данных? | |
---|---|
Владимир Максимов Автор Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
В VFP9 были созданы 2 принципиально новых типа данных: VarChar и BLOB.
С какой целью они были введены в FoxPro? Вопрос вызван в основном особенностями реализации этих типов данных в FoxPro. VarChar Понятно, что речь идет о совестимости с MS SQL. Но разве нельзя было ввести какое-либо дополнительное свойство для Remote View вроде "отсекать концевые пробелы при записи"? Если отвлечься от совместимости с MS SQL, то какова предположительная область применения этого типа данных собственно в среде FoxPro? Пока я вижу одни недостатки от его использования: 1) Он не уменьшит, а увеличит размер базы данных. 2) Его использование требует повышенной бдительности от программиста в отношении настроек SET EXACT, SET ANSII, SET VARCHARMAPPING Причем, если этот тип данных был введен именно для совместимости с MS SQL, то почему были установлены такие нелогичные настройки по умолчанию: CursorGetProp("MapVarchar")=.F. (для Remote View и SQLExec()) и SET VARCHARMAPPING ON. Хотя по логике должно быть с точностью до наоборот. BLOB Что этот тип данных делает такого, чего не мог выполнить старый тип данных Memo (binary) ? Тип VarBinary я рассматриваю как частный случай BLOB, и в отношении него тот же вопрос. Чем он отличается от Memo (binary) в смысле предполагаемой области использования. ------------------ |
Re: Зачем были созданы новые типы данных? | |
---|---|
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Как-то быловался с типом BLOB, который поддерживает MySQL, как написано в хелпе (VFP) BLOB был придуман для полей nText, Text и Image MSSQL. Вот сляпал Remote View - прописал BLOB полю тип BLOB, на форме картинка ставлю ей PictureVal="=BIN" ( поле view) - нет картинки, пишу STRTOFILE(BIN,"C:\TEST.JPG") - получаю JPG файл. Далее вместо BLOB ставлю Memo (Binary) - картинка рисуется сразу - команада STRTOFILE - так же отрабатывает нормально - следовательно Владимир Максимов как всегда прав - я тоже не знаю куда можно привернуть BLOB вместо Memo(Binary) - разве что использовать в XML файлах т.к. BLOB это бинарные данные пропущенные через функцию StrConv(...,15) - Expression to Encoded hexBinary.
Владимиру Маскимову вопрос - Вы случайно не Янус Полуэткович из "Понедельник начинается в субботу" - един в двух лицах. А то как появляетесь на форуме - сразу 2 Владимира Максимова. Это приятно когда хорошего человека много ------------------ Часто бывает так, что есть над чем задуматься, а нечем. |
Re: Зачем были созданы новые типы данных? | |
---|---|
Владимир Максимов Автор Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Цитата:Это у нас на работе глючит Internet и время от времени предлагают переключится на другой IP-адрес (2 варианта). Вот эти 2 адреса, видимо, и вызывают такой эффект. ------------------ |
Re: Зачем были созданы новые типы данных? | |
---|---|
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Зато забавно
------------------ Часто бывает так, что есть над чем задуматься, а нечем. |
Re: Зачем были созданы новые типы данных? | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
1) Размер БД в 90% случаев не увеличится, а если и вырастет, то всего на
RECCOUNT()*1 байт - для varchar поля нужен всего 1 дополнительный бит на поле - причём он хранится в том-же служебном поле что и флаги Null-ов - это уже обсуждалось на форуме. 2) Я пользу вижу в том, что не нужно больше думать о всяких RTrim-ах и насиловать CursorAdapter "функциями преобразования", дабы в Remote-базу не лезли лишние пробелы. Конечно если некто всегда всю работу с базой делал руками, через свои собственные классы и слал INSERT INTO/UPDATE ... то ему это и не очень нужно, но вот всем остальным - очень даже. Кстати как бы ты без этого поля смог ввести в локальный курсор и затем отправить на сервер значение типа: "asd fgh " (обрати внимание на 2 хвостовых пробела) - раньше либо пробелов по плешку (до размера поля) - либо все вырезать - иного не было Да и даже в самом фоксе мне например нравится наличие такого типа поля. Скажем многие функции преобразрования AllTrim/RTrim можно будет просто выкинуть, заменив банальной конкатенацией. Т.е. польза определённо есть. 3) Насчёт настроек - господа, это же beta - и каковы будут настройки в релизе зависит во многом от вас самих - пишите, и да будут услышаны ваши голоса Мне тоже кажется что надо обратно их выставить (для удалённых курсоров включить, для фоксовых запросов - выключить). 4) Насчёт blob - не вижу никаких сложностей в использовании - да это именно так и есть как описано - memo(binary) пропускаемое через strconv() при доступе. Мне пару раз реально приходилось пользоваться именно таким преобразованием, так что вреда я в нём не вижу точно, а польза - ну это конечно не супер-нужная-фича, но всё-же есть 5) varbinary это не memo - это Char(binary) пропскаемый через strconv() при доступе - так что надо сравнивать его именно с "C(xx) NOCPTRANS". В принципе в моих задачах я этим типом никогда не пользовался (в отличие от memo-binary), но вот например для хранения ключа-GUID-а он IMHO очень хорошо подходит (откидывай скобки и дефис - вот тебе и поле) ------------------ WBR, Igor |
Re: Зачем были созданы новые типы данных? | |
---|---|
Владимир Максимов Автор Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Цитата:Я в курсе. Размер поля _NullFlags можно рассчитать по формуле: ?CEILING((N+V)/8) N - это количество полей, в которых допустимо использования значения NULL V - это количество полей типа VarChar или VarBinary Цитата:Почему для решения этой задачи понадобилось вводить новый тип данных, а не модифицировали Remote View (или еще какие-нибудь настройки)? Цитата:Да, такую задачу можно решить только введением нового типа данных или прямой модификации через T-SQL. Но я как-то сомневаюсь, что это очень уж распространенная задача. Обычно требовалось именно "все или ничего" в качестве концевых пробелов. Цитата:Т.е. выгода от VarChar только в операциях сложения строк? И для этого надо было вводить новый тип данных? А насколько усложнится сам процесс работы с символьными строками при совместном использовании Char и VarChar не прикидывал? Например, объединение таблиц по JOIN по полям VarChar? Не проблема, конечно, если не забыть выставить SET ANSI. Но куча воплей в конфе по поводу глюков объединения обеспечена! Цитата:Вопрос не в сложности использования, а зачем это вообще надо? Чем лучше BLOB или VarBinary по сравнению с Memo(binary) и Char(binary)? Что они могут такого, чего не могли поля со свойством binary? Да, кстати, ты уверен, что BLOB и VarBinary - это Char пропущенный через StrConv()? Ведь физически хранится голая последовательность битов. Я предполагаю, что как раз Char требует дополнительных преобразований, а BLOB - это чтение содержимого "как есть". Вообще без преобразований. Или я ошибаюсь? ------------------ |
Re: Зачем были созданы новые типы данных? | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Цитата:Я не думаю что так было бы лучше... SPT тогда тоже модифицировать надо или побоку? Сохранить результат выборки в таблицу, да или просто в другой курсор (ну скажем обработка такая - из одной таблицы через запрос(ы) в дургую перегнать, без участия сервера)... В общем мне кажется что так как сделали оно очень неплохо, и вполне удобно. Я пожалуй даже в чисто фоксовых базах стану использовать Цитата:Нет не только. Просто хранение инфы "в том виде как её ввели", без всяких там дополнений пробелами это очень неплохое улучшение. Цитата:Ну вот - сразу крайности ты сам реально часто где используешь "Join по полям наименований"? Я - очень редко и лишь для очень специфических целей (ну там дубликаты между табличками найти) - в общем это IMHO не есть повседневная работа. Цитата:Ну и что? тогда по твоему не нужно было вообще ничего такого вводить - ни dbc, ни триггера, ни транзакции, ни тем более буферизацию - ибо от этих новшеств даже сегодня масса вопросов у народа возникает. И это при том, что ВСЕ эти задачи можно "руками" проэмулировать в FPD... Порой даже более корректно и просто. Цитата:Философ А зачем вообще нужны компьютеры? Вот я например считаю что 90% того что сегодня "автоматизируют" можно очень успешно решать и без компьютеров вообще Компьютеры лишь усложняют простому человеку жизнь - пообщавшись с юзерами это видно особенно отчётливо Цитата:Чем лучше Integer по сравнению с C(4) NOCPTRANS? Чем лучше AsTopLevel Form по сравнению со _SCREEN? Это IMHO вопросы без ответов. Где-то применимо одно - где-то - другое. Цитата:Ничего. Они лишь дополнительно "конвертируют" результат в ascii-hex числа. Цитата:Нет конечно, я лишь могу видеть вход (dbf/fpt) и выход (? mytable.myfield). О внутренностях "чёрного ящика" могу лишь догадываться как и ты Цитата:Естественно - всё есть голая последовательность битов - и Char и Numeric и Double и Integer... Цитата:Он считывается как последовательность байт - проходит (или НЕ проходит) конвертацию кодовых страниц (опять же из одной последовательности байт перевод в другую). И потом интерпретируется как строка. Для var* вместо просто интерпретации ещё дополнительно очевидно проводится конвертация. Проводится она для "хранимого в памяти представления", или это лишь какой-то бит в variant-е который просто говорит функции вывода (тому-же ?) что при выводе надо не как ASCII код символа это брать, а преобразовать в 2 символа hex кода - я не знаю... Цитата:"как есть" - это набор байт. И так оно всегда и будет. Другое дело как это обрабатывать, как печатать... ------------------ WBR, Igor |
Re: Зачем были созданы новые типы данных? | |
---|---|
Владимир Максимов Автор Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Цитата:С этим, пожалуй, соглашусь. Как-то не подумал о том, что может быть и такая задача. Видимо, просто не попадалась. Хотя, это можно решить и через Memo. ;) Цитата:Нет, вопрос предельно конкретный. Например, есть поля Numeric и Currency. Вроде бы, если речь идет о денежных суммах, они делают одно и то же. Однако есть предмет для сравнения. Currency - экономичнее (физически меньше места занимают), но Numeric - точнее для россиийской бухгалтерии. По приведенным тобой примерам тоже есть свои "За" и "Против". Взвешивая аргументы (и свои личные предпочтения) можно принять решение, что именно использовать. А что можно сказать при сравнении BLOB и Memo(binary)? Что выбрать под конкретную задачу на FoxPro? Где здесь предмет сравнения? Чем они отличаются при реализации приложения? Способом отображения? Ну, так ни один из них и не позиционируется как тип данных для отображения! Эта некая информация, которая требует дополнительной обработки. Просто при работе с одним типом данных мне придется применять одну методику обработки, а с другим - другую (и то, не факт!). Ну и в чем разница? Например, при хранении файлов в таких полях вообще никакой разницы: StrToFile() или COPY MEMO ... Какой тип не используй, результат будет одинаковый. ------------------ |
Re: Зачем были созданы новые типы данных? | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi, Владимир!
Цитата:Именно через Memo и приходилось это решать, но у memo есть масса своих недостатков - основной из которых - распухание fpt от работы в Shared режиме (новая инфа дописывается в конец, даже если она по размену <= старой ) Я так например когда-то хранил параметры (когда ещё хранил их в dbf-ах) - и чтоб не сильно пух fpt приходилось ставить нечто типа
Цитата:Никогда не задумывался над этим, если серьёзно. Один момент я уже сказал (GUID хранить, хотя конечно без дефисов он страшен, но всё-же...). BLOB - ну наверное так удобно сразу файл hex-coded получить... P.S. Может быть Алексей обратит внимание на нашу беседу и просвятит какой же глубинный смысл был в введении этих полей Я кстати и не удивлюсь, если это было сделано исключительно "по просьбам трудящихся" - AUTOINC похоже так-же делали, а потом пришлось доделывать (в 9-ке), ибо изначально он крайне неудобен... Да и в 9-ке всё-же не хватает ему функции возврата "последнего присвоенного для таблицы в рамках заданной датасессии"... Американцы вообще немного странные люди - скажешь им что "а теперь есть BLOB" - радуются, хотя по сути он был всегда... Я боюсь что так скоро мы получим и CLOB вместе с memo, image вместе с General (а что добавить возможность "вытянуть картинку обратно" - и готово) и тому подобные "новые типы" ------------------ WBR, Igor |
Re: Зачем были созданы новые типы данных? | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Я думаю - это диверсия. Ну а теперь серьезно. Это стандартные типы полей, многие СУБД (не только MS SQL) их поддерживают. Было высказано довольно много пожеланий, чтобы эти типы были добавлены. Из-за их отсутствия, существует много трудностей при работе с удаленными источниками данных. Если вы с этим еще не столкнулись, то вам очень и очень повезло. Если в случае с Varchar можно сомневаться и понавесить 15-20 настроек, чтобы автоматически RTRIM-ить данные в тех или иных ситуациях, а через месяц популярной станет новая СУБД, с которой этот подход просто не будет работать, то в случае с Blob и Varbinary вопросов быть не должно. Почему? Да потому что в VFP нет других типов полей для хранения binary данных. То, что Char NOCPTRANS и MEMO NOCPTRANS являются binary типами данных - это глубокое заблуждение. Вот только на днях объяснял это на UT, NOCPTRANS всего лишь отменяет code page translation в момент чтения/записи данных в поле на диск. Во всех остальных ситуациях эти данные подвержены code page translation наравне с обычными Char и MEMO. Простой пример, SET COLLATE TO "Russian" и операции сравнения для Char NOCPTRANS и MEMO NOCPTRANS становятся нечувствительны к регистру букв. Это похоже на работу с binary данными? Индексы по полю Char NOCPTRANS почти бесполезны если CPDBF()!=CPCURRENT(), даже если индекс построен с COLLATE "MACHINE". Что происходит с SPT? Данные из Char NOCPTRANS и MEMO NOCPTRANS передаются как текстовые, не дай бог кодовые страницы на сервере и клиенте отличаются - данные на другом конце "провода" узнать будет сложно. Очень хорошее упражнение попробовать вставить значение больше 8Kb из MEMO NOCPTRANS в поле Image на MS SQL Server. И т.д. и т.п. Цитата: Совсем не факт, да и не вижу особой разницы с NULL полями. Благодаря этому прямой доступ к записи по номеру остается черезвычайно быстрым. Примите ко вниманию, что именно номер записи используется при индексировании. Цитата: Программист всегда должен быть очень бдителен к SET EXACT и SET ANSI. Цитата:В релизе SET VARCHARMAPPING будет OFF по умолчанию. Надеюсь, тогда все будет логично? Aleksey Tsingauz, Visual FoxPro Dev Team |
Re: Зачем были созданы новые типы данных? | |
---|---|
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
2Aleksey
Тогда какого ... в vfp9 в SPT курсорах для BLOB или Image полей SQL сервера ставится General а не BLOB ? Понятно, что в Remote View можно напильником подправить, а для SPT почему ставится General а не BLOB по умолчанию ? ------------------ Часто бывает так, что есть над чем задуматься, а нечем. |
Re: Зачем были созданы новые типы данных? | |
---|---|
Владимир Максимов Автор Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Ничего себе! Выходит, диверсия была проведена когда ввели NOCPTRANS! А введение BLOB - это исправление последствий этой диверсии! Странно, что о таком поведении NOCPTRANS ни слова в описании. Теперь понятно, чем они отличаются.
Цитата:Количество настроек в FoxPro и так уже достаточно велико. Поэтому, если есть возможность, я стараюсь писать программу таким образом, чтобы не зависеть от таких глобальных настроек. При работе с полями Char обойти проблему SET EXACT и SET ANSI довольно просто, добавив концевые пробелы к символьным выражениям: =SEEK(PADR("test",10)) Такой поиск будет правильным вне зависимости от SET EXACT А вот с VarChar такой фокус не пройдет Цитата:Если в паре к ней по умолчанию будет CursorGetProp("MapVarchar")=.F. (для Remote View и SQLExec()). В противном случае - опять непонятки: тип ввели, но для его поддрежания нужны дополнительные настройки?! Теперь кое что прояснилось: BLOB устраняет ряд недостатков, присущих NOCPTRANS. Поскольку содержащаяся в полях NOCPTRANS информация тем не менее рассматривается FoxPro как символы, а не как двоичная последовательность (binary) VarChar, прежде всего, включен для совместимости с серверными базами данных. Область применения его собственно в таблицах FoxPro по прежнему не понятна. ------------------ |
Re: Зачем были созданы новые типы данных? | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi, piva!
Кстати меня тоже всегда интересовал этот вопрос, хотя реально я с image полями не работал (да и вообще перспективы серьёзного импользования MSSQL у нас пока под вопросом - заказчики всё больше на Oracle сидят...) Причём "достать" image было (и есть пока что вообще очень затруднительно - приходилось ручками вправлять тип поля на Memo(binary), что уже само по себе не такая и тривиальная задача, потом только можно было скинуть данные в файл... ------------------ WBR, Igor |
Re: Зачем были созданы новые типы данных? | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Hi, Aleksey Tsingauz!
Вот, теперь значительно понятнее Я как-то совсем забыл что эти типы данных не только к полям относятся, но и к переменным... А тут реально большие отличия будут по сравнению со старой "строкой" в которую и memo и char и они же (binary) конвертились... ------------------ WBR, Igor |
Re: Зачем были созданы новые типы данных? | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Да? Это почему же? Цитата:Все эти настройки по умолчанию OFF, причина на мой взгляд очевидна - обеспечить VFP8 совместимое поведение. В бета версии SET VARCHARMAPPING установлена в ON чисто из соображений тестирования. Цитата: Владимир, по-моему, область применения вполне очевидна - хранение текстовых данных переменной длины не более 254 байт. Игорь даже привел несколько примеров зачем это может быть нужно. Ничего страшного если вы не видите немедленное применение этого типа в своих приложениях. Когда появится надобность, функциональность уже на месте. Делать заключение "включен ТОЛЬКО для совместимости с серверными базами данных" - это загонять себя в какие-то, искуственно созданные, границы в выборе средств в будущем. А озвучивать его на всю "вселенную" - это еще и загонять в эти границы других людей. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Зачем были созданы новые типы данных? | |
---|---|
Aleksey Tsingauz [MSFT] |
Здравствуйте, Вадим!
Цитата: А для совместимости с предыдущими версиями. В идеале, чтобы можно было перекомпилировать существующий код и запустить без всяких изменений. Простой пример, Image поле может содержать "копию" OLE объекта (по-моему, categories.picture в MS SQL базе Northwind использует именно этот формат), General поле как раз умеет работать с этим форматом. В VFP8 приложение запускало запрос, получало назад General поле, без проблем создавало OLE объект и занималось своими делами дальше. Теперь представим, что в VFP9 оно получит Blob, который не привязан ни к какому определенному формату и понятия не имеет что делать с содержимым. Каков результат? "Cломанное" приложение. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Зачем были созданы новые типы данных? | |
---|---|
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Алексей, а нельзя ли ввести некий переключатель типа SET BLOB TO BLOB или SET BLOB TO GENERAL для SPT запросов, а то я не любитель и по ряду причин невсегда использую Remote View.
------------------ Часто бывает так, что есть над чем задуматься, а нечем. |
Re: Зачем были созданы новые типы данных? | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Только что попробовал следующее в бета версии:
Создал форму, бросил на нее Image control, PictureVal= "=foo.f1" Запустил форму, картинка отобразилась. Цитата: BLOB - это последовательность байтов, VFP никакую кодировку не применяет. Aleksey Tsingauz Visual FoxPro Dev Team |
Re: Зачем были созданы новые типы данных? | |
---|---|
Aleksey Tsingauz [MSFT] |
Цитата: Переключатель давно на месте:
|
Re: Зачем были созданы новые типы данных? | |
---|---|
piva Сообщений: 18655 Откуда: Курган Дата регистрации: 24.03.2004 |
Алексей, что-то я погорячился, странно, почему тогда не работало ? Теперь все отлично работает, и про StrConv оказалось ошибкой, потому как просмотр поля BLOB показыает последовательность похожую на StrConv, хотя фактически на диске поле BLOB именно в бинарном виде.
Спасибо, что ткнули носом куда следует. PS. Кстати, и портрет Билла Гейтса (WILLIAM GATES III ) висит у меня на стенке, фотку забрал с сайта БГ и распечатал на цветном принтере. Без шуток [i][small][color=Gray]Отредактировано (22.09.04 12:35) ------------------ Часто бывает так, что есть над чем задуматься, а нечем. |
© 2000-2024 Fox Club  |