Максимальная длина типа 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 мегабайт.

[alex55]

Цитата:

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

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

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

[egorych]

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

[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 столько положить..

[Sada]

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

[Ivanhoe]

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

[egorych]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

[egorych]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[Sada]

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

[blokva]

Цитата:

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

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

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

[Sada]

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

[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)

[Ivanhoe]

Цитата:

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

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

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

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

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

О! Отлично. Мне такой способ в голову не приходил.
Получилось два несвязанных списка.

Цитата:

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

В моем списке 195 полей, есть популярные таблицы EmplTable, AssetTable, CustInvoiceLine, RContractTable.

Щас объединю списки, посмотрю и отвечую подробно.
Но пока мне кажется, что изложенные здесь критерии правильности не изменяются.

[mazzy]

Цитата:

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

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

Отлично. Объединил списки.
DAX4SP2_memo_full.xls

Всего получилось 263 таблицы (из них 32 удаленные) и 368 полей (из них 55 удаленных).

Цитата:

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

есть популярные таблицы EmplTable, AssetTable, CustInvoiceLine, RContractTable.

Я не назвал бы эти таблицы популярными.
Но согласен, что запросы по ним проходят достаточно часто.

По поводу EmplTable я бы поморщился и начал говорить о неправильном проектном решении. Но там предполагается хранить только идентификаторы. Они не такие и большие. Хотя конечно неаккуратненько.

В AssetTable также - неаккуратненько, но особого желания кричать "козлы!" не возникает. Там хранятся текстовые комментарии. И вряд ли действительно большие blob-объекты.

RContract... Ну... блин. плохо. Но терпимо.

А вот RCashTrans, rTax25RegisterTrans, rPayRateTrans - просто отвратительно.
Сделал фильтр по trans. Оказывается в проводках находится 18 memo-полей (из них 7 уже удалено). Среди оставшихся 4 в EPTransactionSumTrans, 3 поля в российских таблицах, и 2 в TaxElectronicDeclarationTrans.
Мне кажется, что это стоит исправлять.

Также мне кажется ошибкой наличие Memo-поля в таблицах InventBatch, InventColor, InventSerial, InventSize. Но тут надо подумать. Поскольку здесь вступает в силу соображение о 256 символах. По этим полям всего-лишь нет поиска и индексов.

Думаю, что критерий правильности остается неизменным

Цитата:

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

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

===================
В связи с появлением нового списка встает вопрос: а как лучше создавать memo-поле - как контейнер или как string с длиной memo?

Так есть таблицы, которые содержат поля, заданные разными способами
SysInetCSS
SysInfolog (!)
tutorial_AuctionItems

В aif-таблицах постоянно разный стиль...

Интересно, это имеет какой-то смысл или так получилось?

[alex55]

Цитата:

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

В связи с появлением нового списка встает вопрос: а как лучше создавать memo-поле - как контейнер или как string с длиной memo?
..
В aif-таблицах постоянно разный стиль...

Интересно, это имеет какой-то смысл или так получилось?

Насколько я слышал (сам пока не проверил) в Container можно положить до 60 MB. Выше утверждали что в String (Memo) до 16 MB. Ну и MSSQL типы: image и ntext, соответственно.