#21
Отправлено 27 Апрель 2012 - 12:32
#22
Отправлено 27 Апрель 2012 - 12:49
Foxes, Мне не интересно, что умеет тот.. Крупные конторы не сидят на счетах, а искпользуют эксчейнч, Сервисменеджеры во всем комплекте и еще огромное количество ПО от MS.. И сами понимаете почем глупо не использвать SQL. ВОТ И ВСЕ,. Все остальное мне често даже было лень читать.. Скажу только одно, попробуйте поадминить 1с с пользвателями больше 30 человек с внутренней базой ))) Я над вами посмеюсь во весь голос ))
В этом и проблема многих - лень читать, а писать не лень
Я вам про Фому, а вы мне про Ерёму.
Кстати - что лично вы понимаете под внутренней базой? SQLite - это внутренняя? А Firebird? А почему?
#23
Отправлено 27 Апрель 2012 - 13:15
Eugeny Gladkih, Гыы.... Вот при все уважении... Я пока вообще ни во что не верю, пока не будет.. А то обещаний много, а реализации нужной мало ((( А уж про нулевую производительность даже не смешно )) Я надеюсь, через пару лет, когда будет нормальная 7 версия, я уже перейду на антивирь от MS ибо все равно в десктоппрофешионал включен.
Сообщение было изменено durashki: 27 Апрель 2012 - 13:18
#24
Отправлено 27 Апрель 2012 - 13:42
Foxes Я понимаю что значит внутренняя, а что внешняя. Давайте так, все что ни из коробки, внешняя. Мне лишь не понравилось Ваше сообщение про изведение как таковой поддержки сиквела. Вот и все.. Я просто поправил сообщение, но отвлекли, не исправил вообщем )))) Я про то что изводить не имеют право..
Согласен. Если БД (СУБД) идет в комплекте с ПО - именуется внутренней, если ставится, настраивается отдельно, независимо - зовется внешней, чистой воды условности, по сути. Посему, вопрос не в том, плохо ли хорошо иметь внутреннюю, вопрос лишь в том, что в качестве нее используется.
MS SQL изводится не будет, насколько я знаю, по определенным причинам. Хотя это не способствует повышению эффективности работы с БД. Потому что разработчики вынуждены учитывать особенности и капризы разных по своей идеологии СУБД.
#25
Отправлено 27 Апрель 2012 - 13:44
Я надеюсь, через пару лет, когда будет нормальная 7 версия, я уже перейду на антивирь от MS ибо все равно в десктоппрофешионал включен.
"Ах! Обмануть меня не трудно!
Я сам обманываться рад..." (с)
#26
Отправлено 27 Апрель 2012 - 16:51
Вы ошибаетесь и даже не понимаете, что ошибаетесь.Если БД (СУБД) идет в комплекте с ПО - именуется внутренней, если ставится, настраивается отдельно, независимо - зовется внешней, чистой воды условности, по сути.
Никто не запрещает комплектовать дистрибутив, например, "экспрессами" от мелкомягких или пророка и молча устанавливать их вместе с "вашим" ПО, но ни тот не другой не перестанут быть внешними базами.
#27
Отправлено 27 Апрель 2012 - 17:21
Вы ошибаетесь и даже не понимаете, что ошибаетесь.
Никто не запрещает комплектовать дистрибутив, например, "экспрессами" от мелкомягких или пророка и молча устанавливать их вместе с "вашим" ПО, но ни тот не другой не перестанут быть внешними базами.
Это условности и вопрос терминологии. Так что никто здесь не ошибается. Чтобы показать ошибочность такого определения - дайте свое определение внутренней и внешней БД и попробуйте его обосновать, что только оно единственно правильное.
Предупреждая возможные попытки - тот факт, что СУБД расположена или может быть расположена на др. ПК - не является критерием.
Мы просто о разном. Вы пытаетесь доказать, что встраиваемая СУБД - синоним внутренней.
#29
Отправлено 27 Апрель 2012 - 22:43
Встраиваемой рулит админ ES, а внешней, вообще говоря, совсем другие люди.А в чем отличия, Василий, для администратора? Между встраиваемой и не встраиваемой?
И этим другим людям гораздло проще создать БД на уже существующем сервере MS SQL, чем ставить отдельный сервер для <впишите имя СУБД>.
Вот и вся разница.
#30
Отправлено 28 Апрель 2012 - 09:27
И этим другим людям гораздло проще создать БД на уже существующем сервере MS SQL
Вот и я про то же самое.. Ту тспор то ни о том, что лучше что хуже.. Но у крупных компаний парки все же стандартизированы, и плодить много ОС, БД, да и вообще серверов смысла нет. Это ТУПО ДОРОГО. Проще купить один большой сервер, на котором будет крутиться сиквел процессорный и на нем будет находится куча БД от всех сервисов..
#31
Отправлено 28 Апрель 2012 - 09:51
Бесспорно, именно поэтому я подчеркивал, что администратору будет все равно, при условии, что:И этим другим людям гораздло проще создать БД на уже существующем сервере MS SQL, чем ставить отдельный сервер для <впишите имя СУБД>.
"Если СУБД будет приходить вместе с ESS, устанавливаться и настраиваться средствами инсталлятора ESS.
Если ESS будет обеспечивать, через тот же веб-интерфейс управление/обслуживание используемой СУБД - разве администратора будет беспокоить - какая СУБД используется?"
#32
Отправлено 28 Апрель 2012 - 12:54
#33
Отправлено 28 Апрель 2012 - 13:27
Ведь вот как администратор ЕС судит по тому, быстрая БД или не очень?? Я помню меня сподвигло на переход одно - после того как перевалили пользоватили за 200, внутренняя начала жутчайше тормозить. На любое действо, например зайти и посмотреть на пользователя либо тупо его перенести в другую группу, все задумывалось огоооо.. Даже удаление требовало достаточного времени.. Тогда я решил что пора..
напомнило анекдот про покупку новой машины, потому что в старой уже все пепельницы полные
Тут, возможно, проблема в том, что не предусмотрено автоматически или через веб-интерфейс делать внутренней БД вакуум и пр. чистки, смазки. А после этих физиопроцедур, она бы бегала еще как молодая до сл. 200 пользователей.
Так или иначе, как уже говорил, насколько я знаю, планов по кардинальному выпиливанию поддерживаемых сейчас СУБД нет. Относительно возможностей обслуживания БД средствами ЕС - тут не знаю.
#34
Отправлено 28 Апрель 2012 - 13:39
Относительно возможностей обслуживания БД средствами ЕС - тут не знаю.
будет, в сл. версиях.
#35
Отправлено 29 Апрель 2012 - 22:22
Я Вам приведу другой пример: у меня 4-6 докторы крутились на внутренней базе с 2006г на системе 2хРIII 900MHz/1Gb RAM. Это был HP NetServer LH3000. Обслуживал без напряга ~1000 клиентов и несколько сабсерверов. С операциями над БД проблем не было, разве что еженедельные непонятные затыки напрягали, когда она ночью бекапилась, пока я тупо не поставил принудительное убивание и запуск процесса сервера перед бекапом, средствами ОС.У меня например на данный момент службы внутренние разнесены на 4х виртуальных серверах. Например серверу WSUS тоже с сиквельной базой, находящейся там же и подключенными обновлениями вообще в другом месте + ЕС сервер с 400 пользвателями легко так живется на виртуалке с очень незначительными ресурсами..
Когда стало ясно что клиентов станет в полтора раза больше и появилась новая железка, то перенес БД на постгрес (512Mb RAM/какой-то зеон 2х ядерный, убитая сказя, на которой чтение/запись идет всего по ~800KB/s, я уж не знаю что с ней делали до меня, что так ухандокали). Оно работает! И работает без проблем (почти - суммарную статистику все-таки долго анализирует). Про перезапуски забыл. Сервера больше полугода в аптайме, с сервисом на пару. Когда я пытался на этой же железке завести MSSQL2005, и использовать его - на 300 клиентах тупо все ложилось, ибо не справлялся IO. Так что не надо про дороговизну, МС гораздо более требователен к железу и его производительность стоит не всегда оправдано, забесплатно можно завести в виртуалке како-нить линух, впилить ему нативный постгрес и забыть о ненужных затратах.
#36
Отправлено 29 Апрель 2012 - 22:40
Какой SQLite будет там?а вот 7ка будет с новой встроенной БД,
#37
Отправлено 29 Апрель 2012 - 23:22
Я Вам приведу другой пример: у меня 4-6 докторы крутились на внутренней базе с 2006г на системе 2хРIII 900MHz/1Gb RAM. Это был HP NetServer LH3000. Обслуживал без напряга ~1000 клиентов и несколько сабсерверов. С операциями над БД проблем не было, разве что еженедельные непонятные затыки напрягали, когда она ночью бекапилась, пока я тупо не поставил принудительное убивание и запуск процесса сервера перед бекапом, средствами ОС.У меня например на данный момент службы внутренние разнесены на 4х виртуальных серверах. Например серверу WSUS тоже с сиквельной базой, находящейся там же и подключенными обновлениями вообще в другом месте + ЕС сервер с 400 пользвателями легко так живется на виртуалке с очень незначительными ресурсами..
Когда стало ясно что клиентов станет в полтора раза больше и появилась новая железка, то перенес БД на постгрес (512Mb RAM/какой-то зеон 2х ядерный, убитая сказя, на которой чтение/запись идет всего по ~800KB/s, я уж не знаю что с ней делали до меня, что так ухандокали). Оно работает! И работает без проблем (почти - суммарную статистику все-таки долго анализирует). Про перезапуски забыл. Сервера больше полугода в аптайме, с сервисом на пару. Когда я пытался на этой же железке завести MSSQL2005, и использовать его - на 300 клиентах тупо все ложилось, ибо не справлялся IO. Так что не надо про дороговизну, МС гораздо более требователен к железу и его производительность стоит не всегда оправдано, забесплатно можно завести в виртуалке како-нить линух, впилить ему нативный постгрес и забыть о ненужных затратах.
а что бы не тормозило - можно вырубить внутренний бэкап, кластеризовать таблицы если еще не, и настроить периодическое выполнение "vacuum full; cluster" раз в неделю и каждый день "analyze". ну и бэкапить родными средствами постгреса. у постгреса очень забавный протокол клиент-сервер, потому драйвер (!) при бэкапе нашими средствами жрет много памяти и потом ее не отдает. в 7ке мы написали собственную реализацию протокола, полностью отказавшись от родного libpq, как оно теперь летает и не потребляет памяти. да, для винды тоже теперь нативный драйвер, ну его, этот ODBC
#38
Отправлено 29 Апрель 2012 - 23:23
Какой SQLite будет там?
3.что-то. оно более, чем на порядок, быстрее 2.x
#40
Отправлено 29 Апрель 2012 - 23:40
Also tagged with one or more of these keywords: СУБД, DrWeb Enterprise
Русские форумы →
Dr.Web Enterprise Suite →
ESS для UNIX+СУБД в ALDАвтор: npc_irs , 03 дек 2020 postgresql, СУБД, ALD и еще 5… |
|
|
||
Русские форумы →
Dr.Web Enterprise Suite →
ES10: Ошибка при смене СУБД с внутренней на MS SQL ServerАвтор: navoiy88 , 02 июл 2015 СУБД, SQL Server |
|
|
Читают тему: 1
0 пользователей, 1 гостей, 0 скрытых