2 ivankr

100 договоров в год - смех :) Городить для них БД не стоит, лучше держи все в XML и доступ через web. дешевле выйдет.

Denis Uskov

А чем, собственно, отличается проектирование под 100 в год, и 100 в неделю? Чисто из спортивного интереса.

Во первых - выбор платформы. На какой СУБД ориентироваться. Для 100 в год и огород незачем городить, а при 100 в неделю набегает вполне приличное количество (52*100), и при такой постановке количество может вырасти и до 100 в день. Второе - это структура самой базы, для малых объемов данных, чаще всего, не требуется партицирования, не стоит усложнять справочную информацию, да и сама структура зависит, в некотором роде, от выбранной платформы.

Denis Uskov

Из вопроса видно, что автор определился с платформой, и скорее всего со структурой БД.

На вопрос автора я ответил ранее, вполне однозначно.

И, пардон, 5200 это приличное кол-во? Да и 100 в день это получается 36500 или это большое кол-во? Что-то я не понял, сколько для Вас большой объем? Я понимаю 1 000 000 это уже солидно.

Отвечаю: понято неправильно. Цифры приведены для примера, не более. А привел я это в ответ на вопрос:

------------------
>AAron
>дэк в ТЗ, наверно должны быть оговорены объемы данных... Одно дело проектировать систему под 100 документов в год, другое под 100 в неделю...

А чем, собственно, отличается проектирование под 100 в год, и 100 в неделю? Чисто из спортивного интереса.
------------------

На самом деле 1'000'000 это дневная норма.

"... не стоит усложнять справочную информацию ..." Надо делать все, что требует заказчик, и это не зависит от кол-ва информации.

Дело не в заказчике - а в структуре базы. Для малых объемов усложнение структуры справочной информации приводит только к лишним трудозатратам. Эффективность работы самой системы практически не повышается.

Denis Uskov
>Jinn
Не хочу больше спорить, каждый выбирает для себя, я свою точку зрения не навязываю. Но мне легче написать, пусть, мало мальскую прогу на FB с возможными пожеланиями и просьбами заказчика в будущем. И потом мороки меньше будет. Но если Вам приятнее XML + Web интерфейс, так это ж Ваше право. Если бы задачу обрисовали поподробнее, то можно было бы говорить о плюсах/минусах. Жаль что автор не указал средство разработки и т.д. :(

Из вопроса видно - автору без разницы какой тип хранения выбрать. С моей точки зрения логичней выбрать XML, поскольку объемы небольшие, система создается для внутреннего пользования. Я бы, конечно, не стал бы даже задавать такой вопрос, а сразу бы стал проектировать документооборот на Oracle :) Просто знаю его лучше всего, поэтому вопрос о выборе инструмента у меня не стоит.

И кстати, "... 1'000'000 это дневная норма ...", это стОлько добавляется? Сколько времени система работает? Сколько сейчас записей? Это просто спортивный интерес, без обид :)

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