[ea...]

Ну так сервер значит надо апгрейдивать, еще раз повторяю , одновременно работает более 30 пользователей и все нормально.... а на счет "бухгалтерской" программы это Вы погорячились, или может просто не знаете возможностей 1С 8 .....

Интересно, а как у Вашей программы обстоит дело с диллерскими версиями?

 

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

[ea...]

так и не услышал ответа про тип БД

я конечно в этом не разбираюсь, но если правильно понял Ваш вопрос, то ответ SQL

[Alekc]

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

Если касается полного фула то брать надо полюбому немца.
А выбор есть не большой Кlaes, Ramasoft и ADULO

[Ravil]

Ramasoft  - Ха ха ха

П.С. 2 года обслуживали и работал с их программой.

[vl_kiev]

так и не услышал ответа про тип БД

я конечно в этом не разбираюсь, но если правильно понял Ваш вопрос, то ответ SQL

сомневаюсь, что большое количество пользователей может без тормозов работать на БД SQL, и дело тут не в админе. Нужно переходить при увеличении пользователей на Oracle

[ea...]

поверьте, никаких тормозов нет!

[vl_kiev]

поверьте у нас был такой процесс, который до замены на Oracle вешал всех, просто видимо у вас задачи попроще проходят

[NickFromOknaInUA]

поверьте у нас был такой процесс, который до замены на Oracle вешал всех, просто видимо у вас задачи попроще проходят

О чем спор? Если бы у Вас были одинаковые задачи, тогда можно было о чем-то разговаривать.

База данных - это всего лишь инструмент. А как правильно его используют разработчики, это другой вопрос. На личном примере - расчетная часть WinCalc работает раза в 4 быстрее, чем два года назад (хотя эти пол секунды особой роли не играли и тогда) . А база данных не изменилась.

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

[Ювелир]

сомневаюсь, что большое количество пользователей может без тормозов работать на БД SQL, и дело тут не в админе. Нужно переходить при увеличении пользователей на Oracle

Vl_kiev, Ви дуже помиляєтесь, і вводите в оману інших. Справа в нерозумінні Вами термінології взагалі і теми конкретно. Наприклад, "БД SQL" - фраза яка не має сенсу: це як "Водій Дороги". Поясню.

1. БД (база даних) - це упорядкований набір даних (наприклад підшивка газет є базою даних). В деяких випадках під БД розуміють Структуру БД, тобто метод упорядкування даних - таблиці, зв'язки, функції БД і т.д. В будь-якому випадку вести розмову тут про БД немає сенсу. Повірте.

2. SQL (структурована мова запитів) - це один із стандартів мов побудування запитів. Запити відправляються програмою до СУБД, СУБД виконує ці запити (стосовно до БД) і дає програмі відповідь.

3. СУБД (система управління базами даних) - це програмна облонка, яка керує даними в БД. В деяких випадках реалізована пасивно, тобто сама структура розміщення даних і є СУБД, але це ми заглибились Головне інше:

4. Oracle (Oracle ) - це компанія. Один із найвідомішіх її продуктів - СУБД Oracle (наприклад - Oracle 11g). СУБД Oracle, серед інших відмінностей, відома ще й тим, що реалізована в ній мова запитів надзвичайно близька до "чистого" стандарту SQL. Таким чином, Ваша теза: "SQL фігня, Oracle рулезз форева" абсурдна.

Тепер далі по темі.
По-перше, SQL найоптимальніша на сьогодні мова для більшості задач з організації багатокористувачевого доступу до БД, і в першу чергу - в локальній мережі. Майже всі популярні на сьогодні СУБД використовують саме SQL.
По-друге, Oracle з точки зору швидкості роботи пасе задніх, і з-за того що жере багато ресурсів сервера, і з-за своєї монструозності. В неї є деякі "фішки" які працюють надзвичайно швидко, але в більшості випадків... Oracle цінується не за швидкість, а за масштабованість: там де треба розташовувати БД (і не одну) транснаціональних корпорацій.
По-третє, швидкість роботи сервера БД в першу чергу залежить не від СУБД, і навіть не від "заліза" сервера, а від того наскільки оптимально розробники спроектували структуру БД і від ефективності реалізованих ними же SQL-запитів до цієї БД.

[Алік]

Не знаю, як Vl_kiev, але я розширив свій компютерний кругозір  . +1

[vl_kiev]

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

[Ювелир]

...при переходе с sql на oracle скорость возрасла и помимо этого при обработке запросов снизилась загрузка на процессор...

Ви, схоже, мене не зрозуміли. Якщо Вам віконна термінологія зрозуміліша, то будь ласка: перейти з SQL на Oracle - це все одно що перейти із пластику на Rehau. Ви перейшли не з SQL, а з якоїсь конкретної СУБД. І не на Oracle, а на якусь конкретну СУБД. Але щоб Ви не казали що я надто мудрую з термінологією, то поясню Вам таку річ: оскільки СУБД від Oracle "працюють" на SQL, то надалі кажіть "при переходе с sql на sql скорость возрасла и помимо этого при обработке запросов снизилась загрузка на процессор... ".

Я бачу, Вас цікавить питання швидкості роботи конкретно Вашого сервера БД. Запитайте про це у свого адміна, він Вам все розповість. Але не нав'язуйте якусь СУБД іншим тому, що як парвильно казав NickFromOknaInUA, СУБД - це просто інструмент; цей інструмент розробник обирає сам в залежності від завдання яке перед ним стоїть. Більше того, найкраща СУБД - це та, яку розробник найкраще знає, тому що саме завдяки цим знанням він примусить її працювати так, як треба.

Іноді замовник ставить умови що і як робити (в тому числі і вибір СУБД), але тут є два варіанти причин: або він дуже добре знає предмет, або він, скажімо так, "дещо недалека людина", яка послухалась якихось лозунгів на форумі ветеринарів. Приклад із життя тут на форумі приводився: "Ваші вікна (ПВХ - прим.редакции) дуже хароші, їх красити треба тільки один раз! Як це не треба красити?!? Не, ви мені тут не розказуйте - моя сусідка сказала що треба красити, а вона брехати не стане!".

[vl_kiev]

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

[NickFromOknaInUA]

тупой пример, при чем здесь соседка, если я говорю про конкретный случай который сам прочувствовал

Вы не поняли. Ювелир хотел сказать, что сам по себе переход на Oracle вряд-ли дал такой ощутимый прирост в быстродействии. Возможно, Oracle и "сгладил" кое-какие недочеты разработчиков, но ускорить на порядок точно не мог. Тем более нельзя просто так сменить сервер баз данных - хоть язык SQL и один для всех, его вариаций просто море. Простые запросы будут работать, а вот сложные (запрос в запросе, хранимые процедуры, просмотры и т.д.) 99% что нет. Так что скорее всего была проведена оптимизация под Oracle при переходе.

Существуют различные независимые тестирование различных платформ СУБД - разница в скорости всего лишь проценты. А вот "кривые руки", как у нас принято выражаться, эту разницу могут увеличить до порядка...

[vl_kiev]

ладно, сформулирую точнее. одна конкретная  процедура при СУБД SQL подвешивал всех пользователей программы и сам мог выполняться около часа, при переходе на СУБД Oracle время ее выполнения 5 минут и ничего не подвисает. перевод проходил не мгновенно, а около 2-х суток. настроен Oracle стандартно, после перехода раюотало около 95% запросов, если даже не больше, остальные подправляли