0

Я пишу программу для клиента. Данные, которые они отправляют нам, - это по существу информация из реляционной базы данных, которая сглаживается, что приводит к чрезвычайно гигантским текстовым файлам с разделителями-запятыми, которые состоят из чрезвычайно избыточной информации, и только несколько полей изменяются в каждой строке.Как я могу хранить большое количество неорганизованных связанных данных и организовывать их по мере их получения?

Я читаю это в типизированном наборе данных и по существу организую данные, которые я получаю в третьей нормальной форме, которая резко сокращает объем избыточности. Оттуда я преобразовываю данные в наборе данных в XML и отправляю их в другую программу для создания форм и операторов.

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

Поскольку ни одна из данных не должна сохраняться (фактически, это не должно быть), фактический RMDB не выглядел бы достойным, если бы я просто закончил очищать его после каждого использования.

Программа также должна запускаться во множестве сред; моя рабочая станция - 64-разрядная версия Windows 7, сервер тестирования - 32-разрядная Windows XP, а производственный сервер - 64-разрядная или 32-разрядная Windows 7, в зависимости от того, на каком сервере он происходит.

+0

Определите «узкое место» - в то время как набор данных может быть тяжелым по сравнению с массивом, похоже, что вам нужны данные в какой-то структуре, поэтому вы можете удалить дублированные поля и т. Д., А набор данных имеет преимущество именованных полей , что упрощает отладку. «Важно то, что данные организованы и понятны, и что он проверяется и проверяется с ограничениями, прежде чем преобразовать его в XML». - вы очень много говорили в наборе данных прямо там ;-). – peterG

+0

@peterG Bottleneck, возможно, не было правильным словом. Но мне все еще интересно, есть ли лучший или более быстрый способ сделать это. На первый взгляд это не похоже; ближайший эквивалент, который я мог найти, - это запустить sqlite, используя соединение в памяти. – sonicbhoc

+0

Так много зависит от обстоятельств приложения и данных - вы говорите текстовый файл - это CSV или что-то подобное? Лично я более уверен в SQL, чем LINQ, поэтому, если бы это был я (я смущен, чтобы упомянуть ;-)), что также повлияло бы на мое решение - также насколько практичным является подход в памяти - это запустить на клиентских компьютерах, на которых может быть XP, например, или вы знаете, что он будет работать на 64-битном 32-Гбайт ящике? Кроме того, насколько важна производительность, а не просто поддержка? Решение DB, в котором вы можете проверить промежуточные таблицы и т. Д., Может быть проще работать, даже если медленнее ... – peterG

ответ

1

IMHO, тогда я бы начал с SQL Express - он разработан, чтобы прокладывать себе путь через эти виды томов данных и адаптироваться к различным платформам, на которых вы работаете; при необходимости он масштабируется до больших версий; и в SSMS у вас есть инструмент для легкого изучения промежуточных результатов и т. д., а импорт .csv прост. И это бесплатно. По всем вышеперечисленным причинам я бы дал SQL Express попробовать и оценить его реальную производительность. Возвращаясь к исходному вопросу, мое мнение гласит, что это разумный подход; Я не думаю, что тебе что-то не хватает.

+0

В новых версиях SQL Express есть опция LocalDB, которая выглядит как идеальное решение. Спасибо за помощь! – sonicbhoc