AntonDr, и сколько баз вы "построили"?
Вид для печати
AntonDr, и сколько баз вы "построили"?
Dracosha Andrew, немеряно "построили"
AntonDr, тогда вы можете, конечно сказать, что такое "база данных"?
Dracosha Andrew, бох с вами, кому это интересно? Если только Вам лично - используйте ЛС.Цитата:
тогда вы можете, конечно сказать, что такое "база данных"?
Хотя вот, неполенился, нашел пример определения: База данных в Visual FoxPro — это совокупность таблиц , отношений между таблицами, индексов, триггеров и хранимых процедур.Цитата:
Сообщение от Dracosha Andrew
Только толку то? Мы же не знаем, какие базы имел ввиду severn и с высказываниями по поводу которых Вы со мной не согласны...
Судя по оптимистичным заявлениямон имел ввиду примерно то же самое.Цитата:
Сообщение от severn
Позвольте вмешаться и немного разъяснить, что я имел в виду.
Под базой данных я, конечно, понимаю совокупность нескольких таблиц.
Только не FoxPro. В нормальной СУБД (самой доступной из них является InterBase) обеспечивается все же ссылочная целостность - т.е. мы, например, не можем удалить клиента, на которого есть ссылки в документах, и т.п.
Обязательно должна быть таблица движений по счетам структуры типа
IDзаписи
Дата
Счет
Клиент
Товар
Склад
и другие аналитические признаки
Сумма
Количество
и, м/б, что-то еще
(Конечно, для обеспечения корректности проводок придется вносить дополнительную логику - но не будем усложнять, чтоб не отвлекаться от основной идеи.)
По такой таблице мы можем легко сосчитать любые нужные остатки и обороты.
Программа для работы с подобной БД - это другой вопрос.
Она может быть простой, либо достаточно сложной.
Может обеспечить простой способ ввода записей, а может позволять вводить документы типа накладных и т.п. и автоматически генерировать проводки.
Важно, что данные из такой таблицы очень просто анализировать.
Мы просто отбираем нужные записи (по нужным счетам, датам, аналитике) и складываем суммы. Можно при этом группировать по клиентам, товарам, и т.п.
Это делается SQL-запросом.
В Excel'е мы делаем подобные вещи, но более ограниченно.
А тут можно построить любые разрезы - по складу, по взаиморасчетам, любые стандартные бухгалтерские отчеты.
Если интересует скорость работы - скажу, что даже без использования механизма промежуточных итогов (1С его использует для ускорения расчетов), т.е. когда для получения остатка по складу мы вынуждены складывать ВСЕ записи по складу "с начала веков", скорость получения отчетов в десятки раз выше той же 1С.
(Предприятие с 3000 документами в месяц работает 3 года без каких-либо неудобств - скорость всех устраивает, размер базы около 100 MB)
severn, Ну Вы согласны, что создать такую базу исходных данных гораздо проще, чем написать прогу, посредством которой бухгалтер (а не программист) мог бы работать с этой базой?
Зависит от того, кто писАл получение остатков в 1С и в InterBase варианте, а так же от количества "веков", за которые надо складывать. Я не утверждаю, что 1С круче InterBase, но на месте руководителя не стал бы внедрять InterBase (как альтернативу 1С-у).Цитата:
т.е. когда для получения остатка по складу мы вынуждены складывать ВСЕ записи по складу "с начала веков", скорость получения отчетов в десятки раз выше той же 1С.
severn, Вы не поверите. но в Visual Foxpro обеспечивается ссылочная целостность, начиная с версии 3.0 (Для справки последняя версия - 9.0) А появилась эта версия практически одновременно с Interbase.
AntonDr, InterBase и 1С несравнимые вещщи. И не могут являтся альтенативой друг другу. Т.к. Interbase это сервер управления базами данных, ему ещё клиентская часть нужна, а 1С это система управления базами данных и клиентская часть одновременно.
А эти вещи и сравнивать нельзя.Цитата:
Сообщение от AntonDr
InterBase - это СУБД,
1С - это СУБД на базе DBF-файлов или SQL Server'а
+ специализированные методы работы с таблицами разных типов (документы, справочники, перечисления ...)
+ логика обработки
+ интерфейсная часть
+ .....
Реализация в 1С СУБД на базе DBF-файлов - просто кошмар. Сотни открытых на всякий случай файлов, неуклюжая организация работы с периодическими реквизитами, какой-то инвалидный язык запросов, ....
Но остальные-то части 1С с чем сравнивать будем?
Мне нравится, как организован интерфейс работы с таблицами значений.
Не нравится работа с партиями товара и еще много чего не нравится.
В конце концов, все решают деньги. Может контора позволить себе построить и поддерживать свою систему учета - хорошо. Только таких контор мало, и специалистов, которые могут все спроектировать не намного больше. И они, слава богу, денюшек хороших стоят.
Ильич, От себя добавлю - 1С на мой взгляд худшая СУБД. По крайне мере из тех, что я видел. Но поскольку это всё-таки пакет разработки, то его недостатки с лихвой покрываются остальным.
я не сравниваю продукт "1С" с продуктом "InterBase". Просто у предприятия, решившего автоматизировать учет, есть два пути:Цитата:
Сообщение от Ильич
1. Смотреть в сторону продуктов 1С
2. Рассматривать другие альтернативы, в частности продукты разработанные с использованием "InterBase".
На этом уровне я их и сравнивал и такое сравнение вполне приемлемо.
Ну тут речь скорее всего про алгоритмы. Не нравится - перепишите.Цитата:
Не нравится работа с партиями товара и еще много чего не нравится.
Согласен. Только я бы еще добавил наличие необходимости в построении и поддержке собственной. Если вместо такой объективной необходимости есть умник, который говорит "1С-мастдай, нам надо то-то и то-то", в связи с этим затрачивается куча денег и времени - то это уже не хорошо.Цитата:
В конце концов, все решают деньги. Может контора позволить себе построить и поддерживать свою систему учета - хорошо. Только таких контор мало, и специалистов, которые могут все спроектировать не намного больше. И они, слава богу, денюшек хороших стоят.
и в догонку: я не рассматриваю 1С как СУБД, и сравниваю 1С и InterBase как два разных инструмента автоматизации учета. И не рассматриваю конечно автоматизацию учета предприятий-гигантов, где одна только бухгалтерия человек 300
Я так понял что AntonDr хотел скзать что, 1С универсальная система и на ней написать можно всё, что угодно, хоть систему управления ракетным комплексом. Только летать эти ракеты будут "нызенько-нызенько" Я прав?
:)
Я и не говорил об InterBase как об альтернативе 1С.
Если сравнивать - то сравнивать работу с БД в 1С и то, что можно сделать средствами InterBase при минимальных усилиях.
Насчет FoxPro - спорить тоже не буду.
Я говорил об анализе таблиц - что мы можем взять достаточно простую структуру, и многое от нее получить.
Конечно же, я согласен, что это только ма-а-аленькая часть работы по созданию программы.
Но мороженка в том, что при таком подходе уже эти минимальные усилия дадут нам работающий результат.
Немножко не прав, я говорил конкретной области применения - автоматизации учета (преимущественно бухгалтерского)Цитата:
Сообщение от Dracosha Andrew
Если говорить об 1С - вы правы, господа, в том, что они разработали хороший подход - справочники, документы, проводки. Не знаю, сами ли они это придумали или позаимствовали, но подход прекрасно работает и позволяет удобно строить логику системы.
Я сам с удовольствием применяю этот подход, позаимствовав у них.
Но их реализация - это просто из рук вон.
Работа с БД сделана безграмотно.
Даже в последней версии допускаются разные вещи в одной колонке -
скажем, в проводках мы имеем колонки Субконто1, Субконто2, Субконто3, и в каждой проводке эти Субконто значат что-то свое.
В результате скорость анализа проводок очень низкая.
Ну, почему не сделать колонки Склад, Товар и т.п. ?
Тогда итоги с произвольным выбором счетов и субконто выбирались бы простым запросом и очень быстро.
Просто обидно бывает, когда люди делают массу работы по разработке системы и получают убогий в сравнении с проделанной работой результат.
потому что больше трех разрезов аналитики как правило не надо.Цитата:
Ну, почему не сделать колонки Склад, Товар и т.п. ?
А зачем скажем 10-му счету колонка "Товар"? С точки зрения предметной области очень даже правильный подход. Кстати - не нравится бухучет - можете использовать регистры и наделать там хоть кучу колонокЦитата:
Даже в последней версии допускаются разные вещи в одной колонке - скажем, в проводках мы имеем колонки Субконто1, Субконто2, Субконто3, и в каждой проводке эти Субконто значат что-то свое
не замечалЦитата:
В результате скорость анализа проводок очень низкая.
тоже не замечалЦитата:
Просто обидно бывает, когда люди делают массу работы по разработке системы и получают убогий в сравнении с проделанной работой результат.
очень поже что Вы имеете ввиду оперативный (управленческий и т.п.) учет, а не бухгалтерский.Цитата:
Сообщение от Аноним (видимо severn)
На основе регистров 1С можем тоже создать любую простую структуру и получить все что нужно.
Не о том речь. Речь о том, что в одной колонке Субконто1 оказывается то Товар, то Склад, и т.п. Это неудобно. И работает медленно - если разбирать межанику SQL-запроса.Цитата:
Сообщение от AntonDr
Вот тут поспорю... Может быть и пять, и больше - смотря что учитвыаем. Для малого предприятия - соглашусь, а для холдинга...Цитата:
Сообщение от AntonDr
Тогда для счета нужно использовать только те колонки субконто, которые соответствуют аналитике данного счета.Цитата:
Сообщение от AntonDr
Это не так сложно сделать.
Но становится удобнее анализировать несколько счетов, если у них используются схожие субконто.
А в существующем варианте даже одинаковые субконто, определенные в разном порядке, создают нам геморрой.
Ну, скажите, какая разница - что сначала указывать - Товар или Склад ?
:)
Вы правы.Цитата:
Сообщение от AntonDr
Но какая разница - ведем мы упр. или бух. учет ?
Если можно их вести одним инструментом - зачем нам использовать два ?
С регистрами - да, но их не получается анализировать в комплексе, как это можно сделать со счетами.
Опять похоже не про бух. учет идет речь. Три, которые есть, вполне обеспечивают требования законодательства к бух. учету. А вот "управленческий" учет каждый себе сам придумывает.Цитата:
Вот тут поспорю... Может быть и пять, и больше - смотря что учитвыаем. Для малого предприятия - соглашусь, а для холдинга...
Не сталкивался с такой ситуацией.Цитата:
регистрами - да, но их не получается анализировать в комплексе, как это можно сделать со счетами.
В том случае, о котором я говорил, была именно бухгалтерская система, и разрабатывалась не самыми дурными спецами - но ей, действительно, придавался некий управленческий функционал.
Кстати, чем лучше реализован управленческий учет - тем проще требования к бухгалтерскому, вы не находите ?
Требования к бухгалтерскому учету достаточно четко оговорены и не зависят от реализации чего-либо. А вот что при удачной реализации управленческого проще получить данные для бухгалтерского - тут согласен.Цитата:
Сообщение от severn
А может это все-таки была система, которая была источником данных для бухучета? Или же система, которая автоматизировала какой-то отдельный участок учета (товары например)?Цитата:
была именно бухгалтерская система, ... но ей, действительно, придавался некий управленческий функционал.
Система бухучета для холдинга.Цитата:
Сообщение от AntonDr
Причем одна конфигурация для всех предприятий.
Просто начальство хотело видеть реализацию по видам деятельности, по товарам, по предприятиям... и т.д.
И еще требовалось изощренно анализировать затраты для обоснования тарифов. Так что тут тоже была куча аналитики.
Причем в качестве источника данных по затратам необходимо было указывать официальные бухгалтерские данные - требование законодательства, как я понял.
Так что частично усложнение диктовалось особенностями деятельности предприятий холдинга, а частично - введением в бухучет управленческого функционала. (Так как отдельной системы упр.учета не было.)
Мне больше нравится подход, когда бух. и упр. учет разделяют - но, по моим наблюдениям, почти каждый заказчик (и многие программисты) проходят этап попыток собрать весь учет в одной системе, в одном плане счетов. Вот, похоже, руководитель проекта как раз проходил такой этап своего развития. :)
Пока я писал, Вы короче сказали о том же.Цитата:
Сообщение от Dracosha Andrew
Думаю, что 1С-ники просто тащат свою архитектуру с тех времен, когда мы работали под DOS. Соблюдают преемственность. V8 не видел вживую, напишите, как там обстоят дела.
Хотя работать с ней, скорей всего, не буду. Мои теперешние клиенты не потянут требований к железу.
В 8-ке они многое улучшили.
Проделанная работа внушает уважение, но...
Но структура БД так и осталась "желающей улучшений".
Странно, вроде в постановке задачи все красиво - чуть-чуть бы доработать...
По языку - добавили модульность, кое-что усовершенствовали очень серьезно, хотя, на мой взгляд, объектно-ориентированный подход в языке дает большие преимущества - но и так сделано много.
Действительно, если б не аппаратные требования - все начали бы массово переходить на нее, как это было с 6-кой.
Радует появление SQL-запросов.
Если б еще это все произошло лет пять назад... ;)
