Организация баз данных #316386

Компания занимается консалтингом, клиентских баз порядка 70ти + постепенно добавляется. Стоит выбор в организации процесса - создавать 70 отдельных баз, или сделать одну базу и завести в ней 70 предприятий. Что будет лучше? Хотелось бы аргументы по категориям: нагрузка на сервер, удобство работы пользователей, наименьшая вероятность нетрадиционного секса без вазелина с программером и т.п. Спасибо.

>создавать 70 отдельных баз, или сделать одну базу и завести в ней 70 предприятий я смотрб вы не ищете легких путей

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

вот если вы создадите 70 отдельных баз , тогда точно сексом с программером будете заниматься :) все зависит от объемов будущей базы, неизвестно же какой будет документооборот

готов выслушать знающий людей, чего уж там. п.1 - хорошая мысль :) мне она сразу в голову не пришла, жаль. п.2 - ну да, хотелось бы типовую конфу с минимумом доработок п.3 - загрузка через разные обработки (клиенты не всегда ведут учет в 1С -> обмен через файлы и т.п.) п.4 - ну собственно, да ... как по мне, отдельные базы проще и привычней - имеется негативный опыт работы с комплексной конфой на 7.7

+ Если грузить данные из файлов то может скорее всего прийдется проводить документы:)- будет трабла  если баз много!

если эти базы будут дорабатываться , то обновлять 70 отдельных баз это конечно да ...... вопрос: зачем тогда 1с сделала многофирменный учет?

>> зачем тогда 1с сделала многофирменный учет? как по мне - для холдингов. хотя, может это я чего то не понимаю ага.

>зачем тогда 1с сделала многофирменный учет Lol для галочи ессно

галочки

мне вот интересно сколько  будет весить  база 70 фирм через год. и как скоро накроется обмен через ублюдочные текстовые файлы.

год не проживет... А чем текстовые файлы не угодили, не понял?... Мне XML очень нравится...

делал я как то обмен через них. куча минусов и ни одного плюса.

XML... зачем мне чужие тормоза и глюки когда я своих могу наплодить?

А какой вариант, если базы удаленно находятся (КОМ и ОЛЕ не катит)? Тем более ХМЛ жмется хорошо, если нужно по фтп/почте кидать... Да и глюки, в основном, от кривых ручек, ИМХО...

Есть, существенный. Не надо прямого доступа к чужой базе. Плоди, кто мешает. XML ОЧЕНЬ многие интенсивно юзают, а ты один умник, говоришь что это г? Как ни поверни - плохо. :)

ну йопт :) ЗЫ я еще тут подумал немного - буду отдельные базы пользовать, скорей всего.

>Тем более ХМЛ жмется хорошо lol. >Да и глюки 2x LOL >Не надо прямого доступа к чужой базе а в какой ноормальной репликации он нужен? >XML ОЧЕНЬ многие интенсивно юзают миллион мух не может ошибаться..? lol >Как ни поверни - плохо задача идиотская вот и плохо. разруха она в головах

и это правильно.

>> задача идиотская вот и плохо. разруха она в головах :)))) вопросов больше не имею.

кроме "лол" сказать нечего?...

Я просто к тому, что геморроя все равно не оберешься. База с кучей фирм будет монструозной и неудобной в работе, куча баз с одной фирмой в каждой - неудобной в обслуживании. Может имеет смысл подумать о промежуточном решении - разделить на части и вести по нескольку(не больше десятка) фирм в одной базе? Хотя там тоже есть недостатки.

>А какой вариант неповеришь.. 1С овцы наконец то должны разродится нормальной репликацией, а не той хренью что ест сейчас.

Какая нахрен репликация? Иногда лучше жевать.

на что сказать? на то что мне предлагают делть реликацию на XML? аргументируя тем что оно жмется хорошо?

Перечитай , п.3, репликатор.

>обмен через файлы оно?

Нет, это к слову. Аргумент в том что базы в разных городах, "непосредственного" доступа к ним нет, а обмен нужен...

репликацией вкуда?

фсем чмоке в этам чати!

+ к примеру.

клиенты не всегда ведут учет в 1С - оно. Как тебе в этом случае разработки 1С помогут - я хотел бы посмотреть.

Как можно делать выводы о размере базы через год , если автор не озвучивает документооборот и требования, предъявляемые к системе - количество одновременно работающих юзеров - сколько в среднем документов в день (интенсивность ввода этих документов) и т.д. Может для этих 70 фирм будет 100 доков в день , а может 7 000 доков в день Если 100 доков в день , то можно и текстовыми файлами обмениваться , если огромный документооборот (тысячи или десятки тысяч в день), то можно и напрямую читать из баз (ADO) даже удаленно. Поэтому пока автор не озвучит исходные данные советовать что-либо бесмысленно.

>непосредственного" доступа к ним нет, а обмен нужен неповеришь - это называется offline репликация. >репликацией вкуда? из одной базы в другую

а в чем же они это делают?

У них спроси. Ты ж у нас гений репликации непойми чего в 1С.

я про бардак уже говорил?

а.. так вариантов масса..ole,xml вышеупомянутый и кстати универсальный, миграция данных из базы в базу средствами скуля(у софтпойнта например. есть готовое решение) и т.п. у 1с прсто свой вариант - планы обмена. Не понимаю твоей реакции по данному вопросу

Причем здесь репликация вообще-то? ) Ты говоришь, что тебе ХМЛ не угодил, а чем я так и не понял...

моя реакция была на самописное нечто через текстовые файлы.

Ты предлагаешь диктовать клиентам, в чем им учет вести?

ага

Тебе не кажется, что это тупо как минимум? А как максимум - может просто не получится выполнить?

одновременных пользователей - порядка 10ти, документооборот - не интенсивный (количество документов в день озвучить не могу, не знаю). базы будут использоваться, в основном, для подготовки и сдачи налоговой отчетности для клиентов. например, в сапе.

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

>подготовки и сдачи налоговой отчетности для клиентов >например, в сапе какие странные люди.. на САП хватило, а на сладчу отчетности нет

Как ты собираешься от 70 баз избавиться при помощи репликации?

Аутсорсинг - слышал такое слово?

>> на САП хватило, а на сладчу отчетности нет ты - идиот. ничего личного.

Превратили ветку в куй знает что...

люди у которых есть САП отдают свои данные по доходам и расходам на сторону? смеялсо

ещё слово против единой базы: наладить распределёнку между базой клиента и вашей копией на порядок проще, чем между общей помойкой и отфильтрованной базой клиента

>смеялсо Весомый аргумент.

>ты - идиот ага.. но ты пришел сюда спрашивать у меня совета.. Lol

у меня длиннее : вы все - идиоты.

для тебя сложно понять даже то, что я спрашивал у форума, а не конкретно у тебя?

=))

из "наименьшая вероятность нетрадиционного секса без вазелина с программером " а ты сам кем работаешь в этой конторе ?

Чем ржать - предложил бы чего-нить :)

граммером :)) так что в этом пункте - кровно заинтересован!

ты его темы посмотри..

мало данных чтобы что нить предлагать, кроме унификации учета у клиентов.

да вроде выяснили, что отдельные базы лучше :) если только вечер пятницы занять на поговорить ...

да, детка :)) посмотри мои темы, выдай мне диагноз по интернету!

Согласился бы, при условии выполнимости этого.

у меня есть вопрос: если вести все в 1 базе, и клиент попросит Вас передать ему ЕГО электронный учет???

1)вот эти десять юзеров со сколькими клиентскими базами будут работать одновременно, если делать каждую базу отдельно ? 2) есть ли классификаторы-справочники , которые должны быть  едиными во всех 70-ти базах и как интенсивно эти справочники будут изменяться ?

нужна команда программеров (вменяемых). и всё. по поводу вариантов высказанных здесь : имхо нужно много баз. + замутить отдельной базой или во всех какой нить блок по взаимосвязям баз. + разработать жёсткий стандарт данных, принимаемых от клиентов.(само представление данных по сути, роли не играет.)

такая задача врят ли всплывет, но принял к сведению ага. 1. у каждого юзера - свой набор баз, но юзера - взаимозаменяемые (т.е. если один уходит в отпуск, другой может его на время отпуска подменить); таким образом, нет жестко закрепленного списка баз за пользователями. одновременно работать - ну с одной базой наверно будет юзер, максимум - с двуми-тремя. 2. скорее нет, чем да (ну может контрагенты местами пересекаются).

в .(само представление данных по сути, роли не играет.) читать как :(само представление данных(а именно, их формат) по сути, роли не играет.)

вообще, тут подтвердили моё мнение насчет "нужно баз". вопрос в всплыл после того, как кто то из "знающих" расписал моему начальнику преимущества ведения в одной базе (мол, и не тормозит, и места меньше занимает, и всё такое). я, честно говоря, с v8 работал мало, потому в своей компетентности засомневался и ткнулся на форум.

он наладит распределёнку и будет выгружать первичный образ узла :))

>Не тормозит Бу-га-га...

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

ну мало ли :) я ж говорю, с 8кой не работал, мож там по сравнению с 7.7 прям всё шоколадно?

1. Как часто будут изменяться , дорабатываться конфигурации? 2. из " 70ти + постепенно добавляется." насколько будут увеличиваться ? т.е. 70 могут легко превратиться в 150 баз? :)

я думаю основные проблемы будут лежать не в области производительности, а в управлении "общими" справочниками и регистрами сведений. Геморно будет добиться чтоб при выгрузке клиенту "его" базы, туда не попадал чужой мусор в то же время если мы полностью ведём бухучёт клиента, а тому база особо и не нужна - тогда и хрен с ним, нехай туда мусор лезет в виде чужих статей ДДС и контров

Или в 1500. %)

по сравнению с "семеркой" у "восмерки"  более высокие требования к железу

ну и подумаешь. на крайняк разделить одну "мегабазу" на две

уж тогда точно лучше управлять десятком баз-ферм, чем 1500 базами

именно поэтому надо более внимательно посмотреть на вариант "Одна база" обновление двух сотен баз превратится в настоящий ад а производительность может не быть критичной, если учёт ведётся сводно:

Вот и я о том же, нету универсального решения. It depends, как говорится...

ну да, зато в отдельной базе, например, можно легко восстановить бэкап недельной давности; да и вообще как то привычней, несмотря на гемор с обновлениями. 1. хотелось бы, чтобы по минимуму 2. т.е. 70 могут легко превратиться в 80 баз :)

с другой стороны распределёнка с фильтрацией данных на 70 узлов создаст дополнительную ОЧЕНЬ высокую нагрузку та же первичная выгрузка может длиться сутки

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

Хорошая идея. Остается обмен данными с клиентами, который надо делать другими средствами, как нравится.

записал в блокнотик :)

согласен, с тем условием, что учет афилированых лиц вести в единой базе тоесть вместо 70 будет 10 и центральная для раздачи обновлений или вариант  двух уровневой, цетр (только конфа) далее уровень управленч баз, а ниже уровень первички,

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

Да при чем тут объемы. Ясен хрен, что каждому средству свое применение, и XML на десяток гигов никому не сдался.

а чёваще, можно и десяток гигов если не надо пересылать через инет, то и не надо сжимать Прикупил девайсик на 2 Тб за 20 тыр (сегодня была ветка с рекламой) и забыл про объём

"Аргумент в том что базы в разных городах, "непосредственного" доступа к ним нет, а обмен нужен...". Еще один учитель, который ничего нормального не видел. Ну у меня базы в 3 городах. А было и в 6 городах России. Никакого гемору с "обменом", как ты советуешь, не делал. Приходят такие, как ты, и глазками хлопают, не понимая, как это такое возможно.

Давай без наездов,а? Или уж обосновывай, как и чего делал, когда обкладываешь. Я тут между прочим одним товарищам предложил обмен через ODBC и был вежливо послан нах.

А скорость? Сначала сутки выгружать, потом сутки загружать?

Ты не знаешь что такое наезды. В общем, советую немного мозгами, хоть иногда, ворочать.

Ты не обосновал ни одного своего высказывания, только дерьмом всех полил. Может не стоит так?

Вообще в делается сразу упор на решение проблемы технически. И все кинулись именно этот аспект обсуждать. Наверное, надо бы, для начала, определиться что значит "занимается консалтингом, клиентских баз"

а ты с чем сравниваешь ? В принципе общепризнанный факт, что XML быстрее чем ОЛЕ честно говоря сравнивать с dbf я тоже поостерёгся бы просто в ДБФ будет выгружать твой рукописный код на тормозном языке 1С, а в XML будет писать платформа непосредственно так штааа... ещё бабушка надвое сказала, а поддерживать сложную структуру данных в dbf файлах или в плоском файле может оказаться слишком дорогим удовольствием. компьютеры они забесплатно работают, а разработчики - нет :)

>> определиться что значит "занимается консалтингом, клиентских баз" а как это можно по разному трактовать? фирма оказывает аудиторские услуги, в т.ч. по подготовке и сдаче налоговой отчетности. клиенты предоставляют информацию, на основании которой эта налоговая отчетность будет формироваться. соответственно, "клиентские базы" - это рабочие базы в фирме, которые ведутся по клиентам (сейчас на 7.7), и в которые загружается инфа ими предоставляемая. иногда эта инфа в виде архива базы 1С, иногда Excel'евские файлы, иногда файлы с определенным форматом (текст, xml). доступа к базам у самих клиентов у меня нет и не будет никогда, требуется выдать ответ на вопрос в том виде, в котором он прозвучал.