При ведении большой таблицы БД (порядка 500 полей) как лучьше поступить:
1 писать запрос в query с параметрами
INSERT (p1,p2 .....p500)values(....)
2 написать хранимую процедуру и осуществлять вставку записей запуская ее с 500 параметрами
Приложение клиента, осуществляющего запись в БД, работает на
том же компе, что и сервер.

???
Будет ли разница в производительноси между 1 и 2 случаями?
Частота записи в таблицу от 2 до 5 раз в секунду

Лентяй koljan27При ведении большой таблицы БД (порядка 500 полей) как лучьше поступить:
1 писать запрос в query с параметрами
INSERT (p1,p2 .....p500)values(....)
2 написать хранимую процедуру и осуществлять вставку записей запуская ее с 500 параметрами
Приложение клиента, осуществляющего запись в БД, работает на
том же компе, что и сервер.

???
Будет ли разница в производительноси между 1 и 2 случаями?
Частота записи в таблицу от 2 до 5 раз в секунду
А мой совет по поводу промежуточных файлов и External Tables решил проигнорировать? Ну, как говориться, хозяин - барин :)

Нет советы я никаие не игнорирую. Вариант с промежуточными файлами очень даже неплох. Если бы поток информации был поболее - это было бы наверное оптимальное, а может быть и единственное решение. Хочу все таки попробовать писать в базу без промежуточных файлов. Чтоб упростить алгоритм ). Количество записей в секунду будет определяться пропускной способностью сервака + время на вычитывание и обработку данных из контроллеров. Думаю 2-4 раза будет получаться.
Хотелось бы теперь просто услышать мнение (а может чей то опыт), как лучше осуществить запись такого количества в БД с помощью инсерта в query или ХП. Или нет особой разницы, и дело лиш во вкусе выбора.

Понятие External Tables пока мне незнакомо. Пытаюсь разобраться. Если есть линки где почитать буде признателен.

PS за рекомендацию спасибо.

Zmeishe f_w_pКроме как телеметрия или что-то подобное ничего придумать не могу:-)
Возможно. Также предположим, что поля типа массив юзать и сложно и неохота.

Но что это за объект исследования, в котором свыше ПЯТИСОТ датчиков относятся к одной группе.

Например, дизель. Температурные датчики.
Всё равно можно разбить на группы.
- 10-20 шт, температура входящего воздуха на входе в каждый цилиндр
- 30-50 шт, температура охлаждающей жидкости в разных точках двигателя
- 10-20 шт, температура в камерах сгорания
- ... , температура отработавших газов на выходе из каждого цилиндра
и т.д.
Для каждой группы своя табличка. Через полгода полезешь в БД и Не запутаешься. А когда всё в одной куче, подумаешь - "Неужели это я такую помойку разработал???"

Задача действительно похожая. )

Просто разбив на несколько таблиц будет сложнее строить графики. И отчеты.
select с нескольких таблиц потом ждать юзеры запаряться)
А полгода в эту таблицу писать никто и не собираеться. "Эксперимент" длиться от 20 минут до нескольких часов. После окончание база данных сохраняеться и в нее больше ничего не добавляеться. Один эксперимент - одна база данных. Потом по необходимости береться любая архивная база и анализируеться другим приложением.
Архив выглядит в виде совокупности файлов БД хранящихся в каталогах.
имя файла = название_эксперимента+дата+время -помоему удобно ) .

ZmeisheПЯТЬСОТ параметров отразить на одном графике - это круто.
Но я бы разбил на группы. Ну не встречал я графиков, где в построении участвует более двух десятков разных параметров.
Обычно разные графики - разная группа параметров.
Либо графики с комбинацией параметров из разных групп, ну не всех же???
на графике параметров не 500 а от 1 до 20.(по выбору пользователя)
Мне кажеться что select из одной таблицы будет быстрее, чем скажем из 5.

ZmeisheРеально на экране пользователь увидит не более 40-50 параметров. Если все 500 пойдут одним списком, он устанет искать те, которые хочет выбрать! И те из выбранных, которые он уже не хочет видеть на графике.
Разбив по группам, хотя бы ради удобства пользователей, дело у них пойдёт гораздо шустрее. Они даже начнут понимать, то чего делают, с научной точки зрения.

пользователь смотрит на графике или формирует отчет не более чем 15 - 20 параметров.
Он выбирает, что ему необходимо отобразить. Скажем он хочет отобразить всего 3 температуры. Если у меня 1 таблица, то выборка будет всего из одной таблицы , а если несколько таблиц - то прийдеться делать select из 3 таблиц (это как демонстрация худшего варианта). Какой select будет легче для сервера? мне кажеться, что из одной таблицы. Естественно, что выборка в первом и втором варианте будет за какой то период (например 5 минут),а не всех данных.
Юзер может захотеть видеть любые параметры, т.е. скомпоновать таблицы по определенным параметрам не получиться.

Скомпоновать не реально, так как юзер может захотеть видеть скажем температуру, вибрацию и еще чего нить. Как тут скомпануеш? Или связывать руки пользователю. Мол смотри токо температуры или смотри токо вибрацию...

Zmeishe авторИли связывать руки пользователю. Мол смотри токо температуры или смотри токо вибрацию...
1 Группа - Температура
1.1 Температура на входе в цилиндры
1.2 Температура в камерах сгорания
2 Группа - Вибрация.
2.1 вибрация фундамента двигателя
2.2 вибрация остова двигателя
3 Группа Шумность
...

Я не пойму ты диссертацию пишешь или курсовик студента первокурсника?
Неужели твои 500 параметров не поддаются классификации по группам?

Выбрал 1 Группу - ометил несколько парамеров
Перешёл в другую группу ещё отметил несколько параметров
Нажал общий 'Ok' - построил график.
Неужели это АРХИсложно.

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

Что касаеться допустимого количество полей - то 500 это помоему далеко не придел.

Меня интересует, стоит ли заморачиваться с хранимыми процедурами для вставки, или они ничего не дадут?