Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Проектирование БД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 9 10 [11] 12   вперед  Ctrl      все
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
Я вот думаю, что мне теперь делать. У меня склад - это территориально удаленное подразделение. Приход товара на склад - это операция совершаемая на складе (в собственной базе данных, на собственном компьютере)
А проводки по этой операции попадают в бухгалтерскую базу данных с помощью героического труда бухгалтера. И все это удалено друг от друга. И каналов связи нет. И осталось мне только повеситься, потому что у меня неправильная корпоративная система, в которой операции совершаются на складе, а проводки бухгалтер лепит постфактум много позже и т.д.
Все, пошел плакать в угол. Наказан, блин.
20 сен 06, 23:42    [3164634]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Не глупите, DmitryOrlov. Толка ведь от этого не будет. И не плачьте. На нет и суда нет. У Вас две (как минимум) системы. Каналов связи нет. В "бухгалтерскую базу данных" попадают операции, а не проводки (здесь то уж могли бы ерунду не говорить). [И она, кстати, вполне может оказаться "корпоративной", к которой уже применимо все о чем здесь "спорят".] Делать Вам "теперь" ничего не нужно. Все что могли, Вы уже сделали, наверное.
21 сен 06, 08:34    [3165125]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
очевидное.
приход 70 на склад С05 в Я10
приход 30 на склад С05 в Я20
приход 50 на склад С05 в Я20
это факты, которые Вы объявляете "не существующими в жизни".
Именно! Такой разбивки, набора фактов в природе не существует. Вам приходится их выдумывать чисто чтобы было куда вставить контировку. А можно было (только незачем) и так:
приход 20 на склад С05 в Я10
приход 50 на склад С05 в Я10
приход 80 на склад С05 в Я20
и еще многими способами.
Чернышев Андрей Леонидович
Потрясающе ! А ведь есть еще партии, МОЛ, отнесение стоимости услуг на стоимость материалов, и т.д. и т.п. (действительно не имеющие никакого отношения к "проводкам").
Итак Вы подтверждаете совершенно бессмысленный (убежден что Вы не сможете привести ни одного аргумента) двойной учет (один + один). Ничего другого я и не ожидал от
подставьте правильное слово:)
21 сен 06, 13:32    [3167356]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
Чернышев Андрей Леонидович
"гыгыгы" - естественный результат непонимания "сущности" обсуждаемого вопроса, 4321е. "Спорить" безрезультатно я постараюсь Вам не позволить. Итак про:
преамбула завораживает силой посылки. но... расплывчата и бессмысленна (беспредметна).
Чернышев Андрей Леонидович
"гм. просветите меня, пжалста. вот имеем мы положим документ "накладная" в РСУБД. строки накладных (товарные позиции), в стандартном рсубдовом решении - это _отдельная таки таблица."
И? иде атвет на вапрос?
Я вас спрашиваю! :0)
и не увиливайте - там же специально помещена просьба отвечать на поставленные вопросы, а не на домыслы. (даже сущ-во впроса - и то опустили).


ладненько. посмотрим на ваши собственные экзерсисы.
Чернышев Андрей Леонидович
Теперь добавляем "проводку" (в том числе по отгрузке - эта "операция" как раз "строка товарной накладной") в "отдельной таблице, как строго типизированную сущность. Итак, где в этом решении, например, дата отгрузки, в какой из трех "таблиц" ? Все суммы по "товарной позиции накладной" в третьей таблице, так ? А почему "количества" не в четвертой, разве "количества" - это не "строго типизированная сущность" ? И т.д.
а вот это все зависит от того, какой набор атрибутов мы считаем "проводкой". (от определения содержимого проводки вы уворачиваетесь). Например если мы договариваемся, что проводка по счетам может иметь _детализацию_ по тем или иным аналитическим признакам, и эта детализация нам нужна _в бухгалтерском_ учете, а не скажем в складском, то количества будут либо в самой таблице проводок (с заполненным признаком аналитики "номенклатура", полем "значение номенклатурного справочника" (т.е. с указателем на номенклатуру товарной позиции) и значением "количество" в поле для числового показателя; это - если заведомо ограничить возможное число аналитических разрезов одной проводки на этапе проектирования - см. напр. 1С - до 3-х разрезов аналитики) либо в той "четвертой таблице" "проводок аналитики" о которой вы упомянули (в этом случае число разрезов не ограничено, и пополнение информации о разрезах постфактум не влияет на саму проводку (по счетам) - а только на ее детализацию (по номенклатуре разрезов)). Встречаются и такие решения. (т.е. "проводка" в ней уже не плоская структура, но структура с подчиненными записями детализации см RS-Balance). То же и с вопросом про дату - конечно можно дату вынести в еще более корневую таблу, чем собсно проводка (ее обычно и называют таблицей "хозяйственных операций" - в _бухгалтерском_ смысле, и дают из нее ссылки на записи журналов "первичных документов" - оснований бухгалтерсокй "хозоперации"), и именно на эту таблу зазвездить собственно "хозяйственные операции" в изначальном смысле (т.е по сути - учет разнородной первички). Но, по размышлении, в ней, в этой табле "бухгалтерских хозопераций" зачастую значимым остается только поле "дата" (остальные отъезжают на уровень либо проводок, либо, если таковой есть, уже на уровень аналитики). Т.ч. можно ,видимо, не городить этого огорода с "бух-хоз-операцией", а смириться с дублированием даты в табле проводок для операций, порождающих множество проводок (что дает возможность индексировать проводки по (датам,счетам) в рсубд). Но можно и городить (есть свои прелести).

Чернышев Андрей Леонидович
Проводка - это процедура, а не структура.
вашу мантру я уже слышал. не внушает.

Ваша "процедура" - это собственно "проведение" (может звучать в русском и как "проводка") хоз.операции по счетам бухгалтерского учета, а вот "запись на счетах БУ" - тоже, кстати сказать - "проводка" - это уже данные (структура) - собственно бухгалтерское "отражение операции" в бух учете. При "процедуре" проводки вы попросту определяете что же записать в "структуры" проводок. :0) За это могут отвечать справочники, но они перестраиваемы. Структуры же не изменямы после закрытия периода учета.
21 сен 06, 16:17    [3168849]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы, ModelR, умышленно что ли "не понимаете"? Какими еще "способами" ???
Я говорю исключительно о фактах. Фактах, понимаете ???
Когда приходовали 100, 70 из них поместили именно в Я10, а 30 именно в Я20.
Вы что издеваетесь что ли ? Зачем же Вы себе голову изначально морочили с "ячейками" ? Я факты в БД регистрирую, никак не зависящие от "бухгалтерского учета". Не нужно мне знать о "контировках" вообще. Они сами по себе автоматически делаются по любым реальным операциям.
Вы просто детский сад настоящий устроили из своего собственного примера.
21 сен 06, 22:19    [3170210]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вы уже просто неправду начали говорить, 4321е ("увиливаете", "уворачиваетесь"). Это нехорошо. Содержимое "проводки", если рассматривать ее (для Вашего "удобства") как "структуру", очевидно и МНОГОКРАТНО приведено. Нет необходимости "договариваться". "Аналитики" (участники события отгрузки) содержатся в операции (связаны с операцией) безо всякого "бухгалтерского учета". А Вы опять талдычите про 1с и "бухгалтерский учет". Советую Вам совсем отказаться от прилагательных в своем лексиконе, может быть это Вам поможет.
"Ваша" мантра (она же "общепринятая") не просто "не внушает", а является ошибкой. Что еще за "запись на счетах БУ" ? Вы говорите о транзакции, в которой данные записываются в БД ? Что еще за "структура", которая тоже "проводка" ? "Структуры" для хранения "остатков" и/или "отклонений" (приращений) (например, Балансовый счет - Имеет отклонение за - День) - это тоже "проводки" ??? Остатки материала на конец периода, или долга перед партнером - это тоже "проводки" ??? Моя "мантра" очевидна, и основана на результатах анализа, а Ваша в чем заключается Вы и сами не знаете:

"конечно можно дату вынести в еще более корневую таблу, чем собсно проводка (ее обычно и называют таблицей "хозяйственных операций" - в _бухгалтерском_ смысле, и дают из нее ссылки на записи журналов "первичных документов" - оснований бухгалтерсокй "хозоперации"), и именно на эту таблу зазвездить собственно "хозяйственные операции" в изначальном смысле (т.е по сути - учет разнородной первички). Но, по размышлении, в ней, в этой табле "бухгалтерских хозопераций" зачастую значимым остается только поле "дата" (остальные отъезжают на уровень либо проводок, либо, если таковой есть, уже на уровень аналитики). Т.ч. можно ,видимо, не городить этого огорода с "бух-хоз-операцией", а смириться с дублированием даты в табле проводок для операций, порождающих множество проводок (что дает возможность индексировать проводки по (датам,счетам) в рсубд). Но можно и городить (есть свои прелести)."

То есть - проектирование базы данных - это творческий процесс. И замечательно. Полностью согласен. И несколько раз порекомендовал хранить "проводки" в "отдельной таблице". Вы с этой моей рекомендацией не согласны что ли ?
21 сен 06, 22:37    [3170225]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1799
Чернышев Андрей Леонидович
Вы просто детский сад настоящий устроили из своего собственного примера.
Как говорил некто Гегель, истина конкретна. И на детсадовском примере все стало яснее ясного. По крайней мере я уже ничего нового добавить не могу.
22 сен 06, 10:41    [3171258]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
4321ё
Guest
Чернышев Андрей Леонидович
Что еще за "запись на счетах БУ" ? Вы говорите о транзакции, в которой данные записываются в БД ? Что еще за "структура", которая тоже "проводка" ? "Структуры" для хранения "остатков" и/или "отклонений" (приращений) (например, Балансовый счет - Имеет отклонение за - День) - это тоже "проводки" ??? Остатки материала на конец периода, или долга перед партнером - это тоже "проводки" ???

1. "запись на счетах" - это основа БУ. Его атом. Такоже назывется "проводкой" (в случае двойной записи по счетам, предложенной еще черт знает когда неким макаронником). Можете почитать буквари по БУ. Именно эти атомы и записываем. В соотвествующе построенные структуры рсубд. (например - выделив эти структуры из общего "тела" (вернее "тел") по разному структурированных "операций в общехозяйственном смысле" - чтобы "избежать дублирования информации".

2. Рад за вас. Вот вы и признались в денормализации. (дублировании данных, что для не рсубд точнее). И остатки-то на конец/начало периода вы храните отдельно, и прочие агрегаты за день. А что ж так. Это ж все расчетные величины. Лихко считаются из остатков на _начало учета_ (от царя гороха) и оборотов за весь этот период. Или таки считаете возможным не всегда хранить данные "в одном месте". Чтобы на это пресловутое "одно место" приключений не нашлось, по причине неудовольствия пользователей? Шутка.

Так все таки вопрос вк вам. Как вы для себя обосновываете необходимость _хранить_ нечто (а все, что хранится - данные, а не процедуры), не являющееся самостояельными данными? Это ж вроде бы расходится с вашей парадигмой. Нет?
22 сен 06, 12:07    [3171967]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
Я все-таки не понимаю. В документе (накладной) что является операцией?Строки документов? Но в документе может быть сотни строк, а документов также может быть тысячи. Для корпоративной системы это нормально. То есть у меня получается операций может быть десятки и сотни тысяч. Бухгалтеру же достаточно получать агрегированые данные по документу, а не построчно. А остальную аналитику вытаскивать можно отдельно, тогда когда она нужна.
А так получается что, в каждом строке документа я должен хранить дополнительные поля с бухгалтерскими счетами. Да плюс еще налоговые счета.
И в чем же здесь правильность?
1.С определенного момента у меня база начнет пухнуть гораздо быстрее, чем если бы я хранил агрегированые записи по операциям в отдельной таблице.
2. Производительность системы для получения бухгалтерской отчетности (вероятно, при большом объеме записей) значительно снизится.
3. Генерация огромного количества операций ни чуть не производительнее, чем генерация агрегированых данных в отдельную таблицу(и получение информации из нее)
4. Разработка решения где данные по операциям(и соответственно проводкам) храняться в документах ничуть не менее сложно(ведь на каждую операцию должна быть отдельная строка-документ со своими правилами учета) и имхо не более надежно, чем запись агрегированых бухгалтерских данных в отдельную таблицу.
22 сен 06, 14:04    [3172918]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Новый круг, 4321е, и опять неправда. Я за Вас не рад, ведь о разумной денормализации я говорил изначально.
Конечно, "лихко считаются", когда я говорил, что "не лихко" ? Особенно элегантно выглядит Ваше "и оборотов [!] за весь [!!] этот [!!!] период" - это я оценил.

Чтобы "избежать дублирования информации" - опять неправда. Перечитайте Ваши рассуждения о дате отгрузки (а про хранение сумм по "товарной позиции накладной" так и осталось тайной).

Что еще за "парадигма" ? Я про эффективное совмещение OLTP и OLAP много раз высказывался в других (соответствующих) темах. К "хранению проводок" это не имеет никакого отношения, ведь "проводка" - это процедура, а не структура, и ее нельзя хранить ни в "оперативной" части БД, ни в "агрегированном хранилище". А вот "остатки" и "обороты" по "счетам" - можно. Но не обязательно. Ничем не отличается от индексов - можно хранить, а можно и не хранить, если и так "все хорошо".
Я не первый раз настоятельно рекомендую Вам хранить "проводки" в "отдельной таблице", но чувствую, что это Вам не нравится. А почему ?
22 сен 06, 23:47    [3175555]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Вот как, DmitryOrlov ! Значит Вы, все-таки, храните "проводки" вместе с "операциями", а не в "отдельной таблице" !
Только сначала Вы группируете операции в "группы операций". Объединяете, например, в приходном ордере материалы с одинаковым "бухгалтерским типом" в одну "группу". И помещаете в "отдельную таблицу" (не находящуюся, заметьте, даже в первой нормальной форме) первичный ключ этой группы (внешний ключ), первичный ключ ПО (внешний ключ), дату прихода, вычисленные суммы (без налогов и налоги) по операциям, входящим в эту "группу операций" (причем разные суммы в разные записи этой дополнительной таблицы) и т.д. И "проводки" в ЭТОЙ ЖЕ ТАБЛИЦЕ !
И при этом говорите, что "операции" + "группы операций" проще (не сложнее), чем просто "операции". Но я то знаю, что именно сложнее, просто потому (знаю), что сам использую вариант с "группами" для некоторых операций.
Хранение "бухгалтерских данных" в операциях проще, чем в "группах операций". БД при этом не "пухнет", а корпоративная производительность не снижается, а наоборот повышается.
23 сен 06, 00:08    [3175596]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
DmitryOrlov
Member

Откуда: Москва
Сообщений: 730
автор
Значит Вы, все-таки, храните "проводки" вместе с "операциями", а не в "отдельной таблице" !

Неужели я это сказал?;)
25 сен 06, 11:12    [3178383]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
FullZero
Member

Откуда: Украина, г.Изюм
Сообщений: 312
какой-то нефильтруемый поток сознания...
26 сен 12, 20:39    [13228373]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
FullZero
какой-то нефильтруемый поток сознания...

А Вам про это понимать не нужно:) Так что не переживайте:)
26 сен 12, 20:54    [13228431]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нашел и пристрелил ЧАЛа
Guest
чуть мозг не взорвался
2 окт 12, 15:47    [13256620]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Нашел и пристрелил ЧАЛа
чуть мозг не взорвался

Это как и при физической нагрузке для неподготовленного человека. Вы думайте сначала по 5 минут в день. И постепенно нагрузку повышайте:) Может быть тогда Вам будет что сказать по существу темы, а не про свой бедный мозг:)
2 окт 12, 20:11    [13258242]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нашел и пристрелил ЧАЛа
Guest
Бредятина, я как погляжу вы данный момент как раз тужитесь на тренировках по своему методу :) и стараетесь попасть немного в тему, но выходит какая-то одноименная с вашей подписью хрень :)
FullZero
какой-то нефильтруемый поток сознания...

особенно последнее сообщение ЧАЛа:)
2 окт 12, 20:59    [13258347]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Нашел и пристрелил ЧАЛа
Бредятина, я как погляжу вы данный момент как раз тужитесь на тренировках по своему методу :) и стараетесь попасть немного в тему, но выходит какая-то одноименная с вашей подписью хрень :)
FullZero
какой-то нефильтруемый поток сознания...

особенно последнее сообщение ЧАЛа:)

Это конструкторское решение (насколько я понимаю Вы у себя в системе храните бухгалтерские проводки в одной таблице с операциями) - ошибка:) Пока Вы считаете правильное решение некой "одноименной хренью", но объяснить это свое понимание не можете. Или не хотите:) А скорее всего, просто пишите что-то из-за обиды на свое непонимание вопроса:) Здесь так очень многие поступают. Это стиль sql.ru. Цель этого стиля мне не вполне понятна. Но Вам, наверное, понятна:)
2 окт 12, 21:08    [13258368]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Konstanrtin
Member

Откуда:
Сообщений: 113
Бредятина
Это конструкторское решение - ошибка:)

Вот ЧАЛа на вас не хватает! :) Он бы зарядил.
Это конструкторское решение
. Решения тут как не было так его и нет. Последнее его сообщение - как будто бы завеса тайны открывается, но больше похоже на
какой-то нефильтруемый поток сознания...
3 окт 12, 13:16    [13261306]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Нашел и пристрелил ЧАЛа
Guest
Бредятина
Это стиль sql.ru. Цель этого стиля мне не вполне понятна.
Из-за этого непонимания Вы, создав новый стиль, отвечаете так же - обидившись, но при этом после каждого предложения ставите смайлик :) Похвально.
Пока Вы считаете правильное решение...
Тут никакого другого нового решения пока не было опубликовано явно, поэтому все до сих пор, и я в том числе, продолжают считать верным способ хранения проводок в отдельной таблице.
3 окт 12, 13:28    [13261404]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Konstanrtin
Решения тут как не было так его и нет. Последнее его сообщение - как будто бы завеса тайны открывается, но больше похоже на какой-то нефильтруемый поток сознания...

Сложно рассчитывать что, даже и такие простые вопросы проектирования БД, будут понятны всем читающим. Вам не понятны. Но они Вас и не интересуют - это же очевидно. Если бы интересовали, то разобрались бы что к чему:) Поэтому (раз не понятны) нужно пнуть обязательно того, кому понятны. Это стандартный стиль sql.ru. То есть, это нормально:)
3 окт 12, 13:55    [13261652]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Нашел и пристрелил ЧАЛа
Из-за этого непонимания Вы, создав новый стиль, отвечаете так же - обидившись, но при этом после каждого предложения ставите смайлик :) Похвально.

Я не создавал стилей, а всего лишь предпочитаю обсуждать вопрос по существу, чего Вы предпочитаете избегать:) Обидеться проще всего. Смысла в этом нет никакого. Поэтому я не обижаюсь принципиально:)
Нашел и пристрелил ЧАЛа
Тут никакого другого нового решения пока не было опубликовано явно, поэтому все до сих пор, и я в том числе, продолжают считать верным способ хранения проводок в отдельной таблице.

Отлично.
3 окт 12, 14:02    [13261718]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Я
Guest
Ужас! Какойто бред типа "О влиянии лунного света на рост телеграфных столбов"
3 окт 12, 15:26    [13262491]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Я
Ужас! Какойто бред типа "О влиянии лунного света на рост телеграфных столбов"

Это точно:)
3 окт 12, 16:14    [13262828]     Ответить | Цитировать Сообщить модератору
 Re: чтоб не изобретать велосипед спрошу у людей  [new]
Бредятина
Guest
Раз уж вернулись к этой, очень интересной теме, промежуточный итог:
1) Никто так и не ответил какие характеристики добавляет "проводка" к "операции". Для меня очевидно, что два БС, один из которых кредитуется, а другой дебетуется (в простой и обычной ситуации, когда для проводки используется одна конкретная сумма из операции).
2) Что именно (какие характеристики каких объектов) "перетаскивается" в таблицу "проводок" в рамках процедуры денормализации (дублирования)? Вероятно, все, что нужно для более производительного выполнения бухгалтерских отчетов, таких, как отчет по БС. Следовательно, туда "перетаскиваются" (вычисляемые характеристики производительность не повысят, в общем случае) значения характеристик не только из операции, по которой делается проводка, но и из других, связанных с операцией, объектов (типов сущностей, таблиц).
3) Таким образом, единственным логичным объяснением хранения "проводок" в отдельной таблице является - денормализация (причем, весьма существенная) для повышения производительности некоторых отчетов. Одной из возможных альтернатив (в рамках простой модели из п. 1)) являются связи:
Операция <-- Кредитует/Кредитуется при выполнении -- Балансовый счет
Операция <-- Дебетует/Дебетуется при выполнении -- Балансовый счет
4 окт 12, 23:19    [13270856]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 8 9 10 [11] 12   вперед  Ctrl      все
Все форумы / Проектирование БД Ответить