Оптимизация DataTable по памяти

[Rupper]

Мы намаялись с этим классом так, что в итоге написали свою версию.
У DataTable кроме того, что он невероятно тяжеловесный в памяти, еще и при сериализации распухает невероятно. Время сериализации-десериализации ужасное. Для целей получить табличку-пробежать по строчкам (что и должно происходить при наличии БД) этой ИМХО лучший вариант. Если задачи еще какие-то, то может подумать о БД? Там все равно работа с большими таблицами лучше организована чем в DataTable.

[Dentty]

Согласен, по возможности, всё нужно выносить в БД. Но в моём случае к таблице применяются различные формулы и скриптованые действия, что пока не удалось полностью перенести в БД. Естественно мы стараемся по минимуму выкачивать данных на клиент, но бывают прецеденты…

[perfectdaemon]

exclusiveStrings.Add(value, value);

Здесь нет ошибки? Может hashed, value?

И я что-то совсем не понимаю, каким образом восстановить данные, ведь exclusiveStrings будет уничтожен после выхода из метода.

[perfectdaemon]

Пятница все-таки сказывается, не сразу понял суть вашего решения.
Отвечу сам себе — ошибки нет и данные будут корректны

[Dentty]

В словарь кладётся один и тот же объект в качестве ключа и в качестве значения. По ключу словарь считает хэш и хранит дальше его. В Value оседает ссылка на экземпляр из кучи. Когда данная строка встречается нам вновь, то словарь найдёт её и вернёт ссылку на уже существующий в куче объект. Эту ссылку мы и присвоем вместо дубликата. Dictionary тут исключительно для линейной скорости поиска.
exclusiveStrings будет уничтожен — вы правы, но экземляру строк будут жить в памяти, т.к. таблица будет держать на них ссылки.

[lair]

В словарь кладётся один и тот же объект в качестве ключа и в качестве значения.

Чем вам хэшсет-то не угодил?

[Dentty]

Используя хэшсет, вы не сможете получить по дубликату ссылку на тот элемент, который уже лежит в хэшсете. Есть Contains, который может просто проверить есть ли уже такой элемент в контейнере. Т.е. в случае дубликата, он вам просто скажет, что есть и всё. Что в принципе логично, потмоу что HashSet — это множество, а не хэш-таблица в чистом виде.

[lair]

Да, я не подумал об этом.

[a_mastrakov]

Вы по сути сделали нормализацию своей таблицы на стороне клиента, это слегка попахивает костылем. Не проще ли было, сделать это на стороне базы, и просто прочитать две таблицы?

[Dentty]

Никто не говорит, что именно так в БД данные и лежат. Как правило, много дубликатов приходит в результате выполнения вьюх (которые джойнят несколько таблиц). Да и заниматься блужданием по FK на стороне клиента — то ещё развлечение.

[olen]

А не проще ли использовать EF с обычными объектами для entity?

В свое время (еще до появления EF) я использовал ADO.NET в одном проекте. В целом все было нормально, но для особо сложной бизнес логики содавали объекты, наполняя их с помощью DataReader. Работать с такими объектами было на порядок удобнее, чем с табличными данными. Так что я не понимаю, зачем сейчас извращаться.

[Dentty]

DataTable, при всей своей избыточности в задачах с readonly-данными, довольно эффективно хранит данные поколоночно (особенно если много value-типов). И если выкинуть с него всю мишуру (о чём я напишу в следующей статье), то получится довольно эффективная структура. Т.е. фактически переписать с нуля, взяв за основу поколоночное хранение. Будет ничем не хуже DTO. По удобству использования, если нужен только произвольный доступ по индексам и именам колонок — самое оно, при минимуме накладных расходов.
То, про что пишете вы, несомненно хорошо, но для другого типа задач, когда DTO переходит в доменные объекты. У нас же была несколько иная задача — к таблице применяются различные формулы и скриптованые действия, которые пока не удалось полностью перенести в БД.
Возвращаясь к статье, подобный подход может помочь не только для DataTable, но и в других задачах — например, XML.