Добрый день всем. В рамках проекта необходимо хранить в базе информацию об индивидах (по сути почти типовой справочник физические лица). Одно но - состав данных будет модифицироваться (добавляются новые, старые удаляются). Данный справочник будет участвовать в формировании нескольких документов. Данные справочника будут обновляться примерно раз в сутки. Индексация справочника должна быть по 2 реквизитам.
Занимают 2 вопроса:
1. Будет ли кошерно ворочаться на соответствующем серваке
2. Какой должен быть сервак
3. Как будут вести себя документы при создании на тонком клиенте?

Сразу говорю, что никаких частых запросов к этому справочнику не идет (пока).

По группам разбей его - нормально будет

(1) Всмысле использовать иерархию в справочнике?

а какая разница сколько элементов в справочнике?

(2) Что в моей фразе не понятно?

(4) Зачем разбивать непонятно. Какую проблему это решит? В Запросе обращаться к конкретной группе?

(6) Зачем же откладывать? Если мне непонятно, я иду на соответствующий форум и спрашиваю людей, которые разбираются в вопросе. Так сказать перенять опыт.

(0) >>1. Будет ли кошерно ворочаться на соответствующем серваке
На соответствующем будет.

>>2. Какой должен быть сервак
Соответствующим задаче.

>>3. Как будут вести себя документы при создании на тонком клиенте?
Вопросов было заявлено два, а это уже третий. Ну да ладно. Нормально будут себя вести.

(8) вообще справедливо.
Тогда более четкий вопрос. Как минимизировать распухание справочника? Т.е. некоторые позиции должны удаляться, но если завязаны на документах не получится.

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

"Данный справочник будет участвовать в формировании нескольких документов"

Каким образом?

(11) будет заводиться карточка учета - документ. Начинается с реквизита типом данного справочника. После по этим карточкам формируется некий реестр.

(10) именно так и должно быть. Проверить пока не на чем, а по факту решать проблемы проектирования как то не очень хочется.

1. какой критерий для удаления элементов?
2. "данные будут обновлятся раз в сутки" вот тут поподробнее, сколько элементов добавляется, что при этом проверяется и т.д.

(10) форме пофиг сколько в справочнике элементов, главное, что бы динамический список был а не дерево.

в моей поделки по анализу 1сд я грузил базу и получал около 100 лямов в справочнике.... нормально форма работала....

(14) 1. по сути критерий удаления - смерть индивида. Т.е. полностью и безвозвратно. Соответственно хранить информацию не имеет смысла вообще.
2. Приходит реестр изменений в справочнике (в среднем 2 - 3 тыс.) пропорции добавления / удаления могут быть разные. Возможно периодичность будет не сутки, но в ТЗ написано так. Так же будет сформирован реестр 4 - 5 тыс. с изменение некоторых реквизитов справочника.

(9) А зачем?
Вообще я придумал в свое время такую тему для скрывания неактуальных записей: в справочник добавляется реквизит "Неактуальный", в модуле менеджера в событии ОбработкаПолученияДанныхВыбора добавляется одна строчка, добавляющая отбор по этому реквизиту, в форме списка через отбор, видимый пользователю настраивается галочка на форме "Включая неактуальные".

(17) хороший способ, сделаю похожий алгоритм. Но главная задача - распухание базы. См (16)

(18) распухание базы основанное на смерти - это не проблема вообще....

15 лямов за 20 лет вырастет максимум в 2 раза (если за 20 лев произойдет полная ротация всех пенсионеров...)

база которая не рассчитанная на рост в 10 раз за 10 лет - хреновая база.....

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

(18) одна ссылка весит 16 байт. Строковые и числовые реквизиты тоже можно посчитать. Умножь размер строки на количество строк и пойми, что всё тлен.

Понял, спасибо. Буду реализовывать.

(18) Про распухание базы вообще не парься. Копейки.

(16) Эээ... А как фиксируется смерть индивида?

Удалил ты запись, а через месяц "мертвец" воскрес с криком "Чувачки! Это ошибка! Я живой". А у тебя уже вся инфа по несчастному дяденьке удалена...