Максимальная длина типа String в DAX 4.0

[alex55]

1. В документации (http://msdn.microsoft.com/en-us/libr...72(AX.10).aspx) упоминается некая "максимальная длина", но чему она равна пока найти не удалось, может кто подскажет? Экспериментальным путем удалось объявить максимальную длину чуть более, чем 2.0 E9, далее начинает ругаться компилятор.

2. Какова максимальная длина поля таблицы с типом String (не Memo)? 1999 символов - я правильно понимаю? (При превышении - ошибка SQL на сохранении).

3. Какова максимальная длина поля таблицы типа String c "подтипом" Memo?

[Sada]

Memo гигантское, коллеги подсказывают 16 мегабайт.

[egorych]

Тут уже вступают в действие ограничения SQL Server, получается -
1. строковое поле - 4000байт, что в случае unicode = 2000 символов
2. тип memo - суть varchar(max) - 2Gb данных.

[Sada]

2 Gb о_О. Мемо вообще предпочитаю не использовать. Только в оч крайних случаях. База может вырасти до невероятных размеров

[Ivanhoe]

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

[Sada]

Не нравится мне оно

[alex55]

Цитата:

Сообщение от egorych

Тут уже вступают в действие ограничения SQL Server, получается -
1. строковое поле - 4000байт, что в случае unicode = 2000 символов
2. тип memo - суть varchar(max) - 2Gb данных.

1. Для MSSQL 2005, насколько я понял, DAX хранит String в nvarchar - до 4000 символов юникода макс., теоретически (http://msdn.microsoft.com/en-us/libr...9(SQL.90).aspx). То есть получается, что ограничение все же аксаптовое, в данном случае..

2. Посмотрел для Memo - хранится в ntext - до 1,073,741,823 юникода, теоретически (http://msdn.microsoft.com/en-us/libr...3(SQL.90).aspx). Вопрос лишь в том, даст ли DAX столько положить..

[blokva]

Цитата:

Сообщение от Sada

Не нравится мне оно

Это наверное от xBASE систем чувство осталось!

[egorych]

Цитата:

Сообщение от Ivanhoe

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

Не совсем так - МОЖНО НАСТРОИТЬ, чтоб они хранились отдельно.

[mazzy]

Цитата:

Сообщение от Ivanhoe

В чем проблема его использования?

Информация по старым версиям. Может быть в последних исправили.

Предположим, в записи содержится memo-поле.
В этом случае выборка select * from... будет выбирать и мемо-поле среди остальных.
Что приведет к огромному трафику, тормозам передачи по сети и прочим радостям.
Во многих случаях, по умолчанию Аксапта делает именно такую выборку.

Если включен автовыбор полей, то Аксапта не делает разницы между memo и обычным полем и при малейшей необходимости тянет все. что приводит к трафику и тормозам.

поэтому memo-поля раньше рекомендовалось выделять в отдельные таблицы.

Вроде в последних версиях что-то делали с мемо-полями.
Но не помню. Надо проверять.

[Sada]

Вот! Интуиция не подвела Плохие они - memo поля.

[egorych]

Цитата:

Сообщение от mazzy

...Предположим, в записи содержится memo-поле.
В этом случае выборка select * from... будет выбирать и мемо-поле среди остальных.
Что приведет к огромному трафику, тормозам передачи по сети и прочим радостям...

Можно я опять немного встряну?
Тут все зависит от того, скоко в ентом меме хранится! Суть в чем - первые 256 символов поля по своему хранению в БД ничем не отличаются от обычного varchar и увеличить трафик ну никак не смогут! Вот если больше, тогда возможны "лишние" искания сервера, дабы найти данные поля которые будут немного в другом месте файла данных храниться. Но опять-же "огромный трафик" - что-то в районе сказок!

[alex55]

Цитата:

Сообщение от Sada

Memo гигантское, коллеги подсказывают 16 мегабайт.

Спасибо. Будет время, поэксперементирую.

[mazzy]

Цитата:

Сообщение от egorych

Можно я опять немного встряну?
Тут все зависит от того, скоко в ентом меме хранится! Суть в чем - первые 256 символов поля по своему хранению в БД ничем не отличаются от обычного varchar и увеличить трафик ну никак не смогут!

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

Если же в memo-поле в основном хранятся строки до 256 символов, то это скорее ошибка архитектуры, поскольку memo-поля не индексируются.

Цитата:

Сообщение от egorych

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

Вы сейчас о дисковых операциях SQL-сервера.
Я о сетевом трафике о перемещениях данных в памяти сервера.

Ведь работу с этими данными будет выполнять AOS или аксаптовский клиент.
А они как должны получить значение memo-поля
огромный трафик будет между SQL'ем и AOS'ом/клиентом

[Ivanhoe]

Хранение memo:
http://www.sql.ru/articles/mssql/200...eRecords.shtml

Поиск таблиц в АОТ, где есть memo поля, дает достаточно много ссылок на таблицы в т.ч. на слое sys, среди которых не только справочники.

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

[mazzy]

Цитата:

Сообщение от Ivanhoe

дает достаточно много ссылок на таблицы

Мне нравится чеканная формулировка "достаточно много".
Почти как "чуть менее, чем полный"

Я привел список memo-полей в ax4.0.
Он содержит 174 поля в 125 таблицах.
ax4.0 - список memo-полей.xls

Если проанализировать, то в основном это поля для хранения сообщений об ошибках.
Зачастую хранятся параметры/шаблоны в контейнерах.
Часто хранятся запросы (Query)
Есть примеры хранения удаленных заказов/закупок в memo-полях
Ну и конечно хранятся изображения.

Есть memo-поля, которые находятся за гранью добра и зла - это Amounts в книгах покупок и продаж...

Цитата:

Сообщение от Ivanhoe

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

Нормальное.
Только не надо вставлять их в таблицы, которые часто выбираются. А также не стоит вставлять поля в таблицы, которые кэшируются.

Например вставить memo-поле в inventTrans, LedgerTrans, Currency, ExchRates и т.п. - будет огромной ошибкой, поскольку трафик будет забит этими мемо-полями.
Вставить memo-поле в CompanyInfo или LedgerParameters - будет огромной ошибкой, поскольку кэш забьется этим мемо-полем и перестанет работать как должно. (Обратите внимание на поле DEL_Logo в CompanyInfo )

А вот вставить memo-поле в специальную таблицу CompanyImage или специальную таблицу DocuField - почему бы и нет?

Цитата:

А ведь, кажется, так просто запомнить, что, например, раскаленной докрасна кочергой можно обжечься, если будешь держать ее в руках слишком долго; что если ОЧЕНЬ глубоко порезать палец ножом, из этого пальца, как правило, пойдет кровь, и так далее и тому подобное.

И уж Алиса-то отлично помнила, что если выпьешь слишком много из бутылки, на которой нарисованы череп и кости и написано "Яд!", то почти наверняка тебе не поздоровится (то есть состояние твоего здоровья может ухудшиться).

(C)

[sukhanchik]

Еще 5 копеек про мемо-поля. Их нельзя впихнуть в условие Where (следствие их неиндексируемости). А также - по ним невозможен поиск.
Ряд консалтиновых компаний используют в своей работе GPT (General Problem Tracker) - систему запросов клиентов с контролем их исполнения. Не знаю - пошла ли терминология от Колумбуса или нет - это неважно. Важно то, что описания задач и комментарии к ним - руки чешутся сделать мемо-полями (типа информации может быть много). Однако - это решение является архитектурной ошибкой (на мой взгляд), т.к. впоследствии возникает задача поиска по запросам или комментариям, а по мемо-полю этого сделать увы - нельзя. Я говорю о GPT, реализованного на Аксапте.

Это в качестве примера. Ряд остальных доводов хорошо расписал Mazzy

[alex55]

Цитата:

Сообщение от sukhanchik

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

А какие более правильные альтернативы существуют в DAX, если нужно хранить более чем 1999 символов в документе?

Собственно получается задача полнотекстового поиска? Ее вообще оптимально будет средствами DAX решать?

[mazzy]

Цитата:

Сообщение от alex55

А какие более правильные альтернативы существуют в DAX, если нужно хранить более чем 1999 символов в документе?

Это не совсем полный вопрос.
Правильный вопрос: как хранить более чем 1999 символов НА РАЗНЫХ ЯЗЫКАХ.
Отдельной таблицей.
См. как сделано описание номенклатуры или Представления номенклатуры: одной номенклатуре может соответствовать несколько описаний на разных языках.

Цитата:

Сообщение от alex55

Собственно получается задача полнотекстового поиска? Ее вообще оптимально будет средствами DAX решать?

Полнотекстовый поиск средствами DAX - не очень. Он работает только по текстовым полям и не работает по memo-полям.
См. как сделан Агент данных (data crawler).

(в сторону) Кстати, может быть поэтому и не используют memo-поля для хранения описаний на разных языках.

[Ivanhoe]

Цитата:

Сообщение от mazzy

Мне нравится чеканная формулировка "достаточно много".
Почти как "чуть менее, чем полный"

Формулировка родилась после поиска по АОТу. Решил, что никому не будет интересен список на форуме - кто захочет, сам посмотрит.

Цитата:

Сообщение от mazzy

Я привел список memo-полей в ax4.0.
Он содержит 174 поля в 125 таблицах.
Вложение 4235

Посмотрел Ваш список, не нашел некоторых таблиц, сделал свой.

В Вашем списке выборочно посмотрел поля - у них тип Контейнер, а не String (MEMO). В моем списке 195 полей, есть популярные таблицы EmplTable, AssetTable, CustInvoiceLine, RContractTable.