Закачка данных в DataSet из базы SQL SERVER, какой объем допустимо закачивать?

Есть база на серваке.

ДатаСет - это некая мобильная база в оперативных мозгах компа. Так вот вопрос , какой объем данных допустимо закачивать в ДатаСет, например на серваке есть таблица где примерно 50 000 записей и 10 полей.

Что будет если для закачки данных в Датасете исчерпается вся оперативная память? Свопиться на винт будет?

Половина полей текстовые , половина int. Есть ли смысл писать хранимки на сервере , запросы и прочую ботву или качать это на локальные компы и обрабатывать локально. Для меня было бы проще написать обработку и выборку данных уже из датасета через Датавью.

Компы мощные пни 4 , 3 ГигаГерц процы и 512 метров памяти? Сетка хорошая и гари на 100 мегабит. Кол-во клиентов юзеров, чуть больше 30 ...

Жду мнения гуру.

Посмотри статью "Модель работы briefcase"
http://www.rsdn.ru/article/db/briefcase1.xml

Спасибо , почитал. Там правда про АДО... Но кое что для себя нашел.

Гриня

Есть база на серваке. ДатаСет - это некая мобильная база в оперативных мозгах компа. Так вот вопрос , какой объем данных допустимо закачивать в ДатаСет, например на серваке есть таблица где примерно 50 000 записей и 10 полей. Что будет если для закачки данных в Датасете исчерпается вся оперативная память? Свопиться на винт будет? Половина полей текстовые , половина int. Есть ли смысл писать хранимки на сервере , запросы и прочую ботву или качать это на локальные компы и обрабатывать локально. Для меня было бы проще написать обработку и выборку данных уже из датасета через Датавью. Компы мощные пни 4 , 3 ГигаГерц процы и 512 метров памяти? Сетка хорошая и гари на 100 мегабит. Кол-во клиентов юзеров, чуть больше 30 ... Жду мнения гуру.

С объемом данных проблем нет. С обработкой - как напишите.
Только помните, что
1 во многом вы берете на себя работу сервера базы данных
2 DataSet - это не "некая мобильная база в оперативных мозгах компа" поэтому:
3 Из набора "хранимки на сервере , запросы и прочую ботву " в DataSet можно закачать далеко не все.

Перед проектированием рекомендую подумать как вы будете обрабатывать конкурентные изменения одних данных разными пользователями. Это то, что в статье от AiSK написано в разделе Синхронизация данных с сервером

ИМХО: модель briefcase имеет смысл использовать, когда существует необходимость работы пользователей с данными, а непосредственная связь с сервером БД отсутствует. Как только она (связь) появляется, лучше переходить на обычный клиент-сервер

2 Alexey Kudinov

А я и делаю в обычной архитектуре клиент-сервер.

Конфликты при редактровании записей на серваке разными пользователями могут быть , но вот как их обойти? Использовать блокировку записей средствами АДО.НЕТ ?

Гриня

А я и делаю в обычной архитектуре клиент-сервер.

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

Гриня

Конфликты при редактровании записей на серваке разными пользователями могут быть , но вот как их обойти? Использовать блокировку записей средствами АДО.НЕТ ?

Не могут быть, а будут. Как их обходить - решать вам. Использовать блокировку записей средствами АДО.НЕТ - это хорошее решение.

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

Требования бизнеса по обеспечению работы мобильных пользователей http://www.rsdn.ru/article/db/briefcase1.xml

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

Мой вам совет - если не хотите работать с "чистым SQL" посмотрите в сторону Data Binding. Ado.Net отлично развит в этом направлении. Таким образом вы и обработку сделаете через DataSet, DataTable, DataView etc (как вы хотите) и данные лишний раз перекачивать не будете. И с блокировками разберутся Ado.net и SQL Server

Большое спасибо. Очень хорошо объяснили.

Через DataBinding поддерживается постоянное соединение ? Верно? Это концепция работы со связанными данными?

Т.е мне надо работать в таком стиле.

Связывать таблицы SQL SERVER (с помощью DataBindings ) с ДатаСетами и работать. Верно?

А я сейчас качаю данные с помощью sqlcommand / sqldatareader / sqlcommand ....

Извините за мое ламерство , но как хоть начать построение такого типа приложения на базе DataBindings . Задача тривиальная вообщем и известная, на сервере есть куча данные и мне надо просто работать с записями таблиц и делать выборки. И все.

Подскажите с чего начать Алексей, чтобы прога на NET с помощью DataBindings общалась со скуль сервером.

Я Вам очень благодарен, вы мне глаза открыли. Помогите сделать первый шаг и дальше я пойду сам.

Начать следует с чтения MSDN и поиска примеров.
Наберите в любом поисковике ".Net Data Binding Windows Forms"

Например
http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=633

http://www.akadia.com/services/dotnet_databinding.html

http://www.codeproject.com/vb/net/databindingconcepts.asp

окунаюсь в доку. Спасибо!