Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 25   вперед  Ctrl
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
2Urri
>Что значит, убедил! Требую контраргументов ;-)

раз уж вы считаете деньги, то можно рассказать как вы боритесь:

1.
update bank1 set balance = balance - 2000000 where id=20 ;
update bank2 set balance = balance + 2000000 where id=21 ;

в bank1.dbf все коректно записалось, а вот пока открывался bank2.dbf клиент грузанулся, деньги достаются казино ?

2. каждый оператор имеет право переводить деньги со счетов своих клиентов, при этом строго учитывается кто и когда перевел деньги. как защитить dbf чтоб оператор не мог от имени президента переводить бабло куда ему вздумается и зачищать свои следы ?

3. select sum(bablo), client from bank1 ;
пол файлика скачалось оператору, но тут у него запускается скандиск, из-за этого селект закончится только к утру. как вы отслеживаете все машины в сети чтоб на них не дайбог ничего не запустилось, чтоб остальные не ждали пока секлктик не отпустит блокировки.
10 май 05, 19:28    [1527807]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Мне, кстати, вот что нравится в этом споре
Сторонники КС кричат, что у нас есть такие сервера (но мы вам их не покажем), стоимостью в 40-50-60-100 килобаксов, причем таких серверов у нас несколько, а каждый такой сервер порвер любого клиента на фашистский крест...
И те же самые сторонники КС плачут, что дескать живут они за МКАДом, сами не местные, на вокзале украли все документы, и кроме как P-133 с 32Мб ничего себе позволить не могут.

Определились бы уже в конце концов - с какой стороны от МКАДа вы живете.
10 май 05, 19:28    [1527808]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
За МКАДом КС хорошо, потому что клиенты слабые, внутри потому что серваки БД очень сильные. И там и там получается П2 для КС очень кстати.
10 май 05, 19:35    [1527819]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
vadiminfo
За МКАДом КС хорошо, потому что клиенты слабые, внутри потому что серваки БД очень сильные. И там и там получается П2 для КС очень кстати.

П2 - это необходимость установки СУБД?
Да нету такой проблемы. Ни за МКАДом, ни внутри него.
Не выдумывайте.
И выкиньте наконец свои институтские учебники.
А то я достану свою книжку с детскими сказками и добрыми феями. По крайней мере у нас будут одинаковые по своей бредовости книжки.
10 май 05, 19:40    [1527825]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЛП

П2 - это необходимость установки СУБД?

На каждом клиенте в ФС архитектуре.

ЛП

Да нету такой проблемы. Ни за МКАДом, ни внутри него.

Вы же тока сказали, что за МКАДом слабые клиенты. Делаем вывод: относительно интеллектуальная СУБД туда совсем не влезет. А Внутри МКАДа мощные серваки. Делаем вывод: обработка запросов на таком выглядит более убедительно, скорее всего.

ЛП

И выкиньте наконец свои институтские учебники.

Для этого нужно слово каких-то светил, чей авторитет был общепризнанным на мировом уровне.

ЛП

А то я достану свою книжку с детскими сказками и добрыми феями. По крайней мере у нас будут одинаковые по своей бредовости книжки.

Доставайте. Сказки, возможно, очень большое достижение человечской эволючии. Воображение, однако. То чего нам с Вами не хватает.
10 май 05, 19:55    [1527848]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
ЛП
2 Urri
А вдумайтесь, ведь для обеспечения этой самой консистентности и КС (если СУБД - блокировочник) ставит те самые блокировки, из за которых, между прочим, другие транзакции откладываются.

Ахтунг!
Сейчас начнется спор "Версионник vs Блокировочник", и весь этот топик взорвется к ипиням.

Лучше скажите мне - фокспро ближе к версионникам или к блокировочникам?
Аксес, например, гораздо ближе к версионникам. И это стоит многих нервных клеток тем, кто переходит с аксеса на казалось бы естественный MS SQL Server.
Хрен его знает. Старый фокс - видимо, однозначно ближе к блокировочникам. Если позволить старому фоксу работать на полном автомате с данными непосредственно из таблицы (например, просто в browse-окне, все настройки по-умолчанию), то блокировка записи будет сделана в момент начала редактирования записи и снята - в момент перехода к другой записи. В случае, если у кого-то запись залочена, у другого пытающегося с ней работать фокс напишет "Attempting to lock..." - и будет пытаться заблокировать, пока другой не отпустит. Лично я в старом фоксе для обеспечения эксклюзивного доступа к записи всегда ставил блокировки вручную, причем как оптимистические (только на момент сохранения изменений в таблице), так и пессимистические (на все время, с начала открытия записи в форме; их не любил, но иногда и они были нужны).
А вот Visual FoxPro - трудно сказать. Дело в том, что тут как использовать. Ведь даже если мы работаем не напрямую с таблицей, а с полученным на ее основе курсором, то уже фактически мы работаем с версией данных. Или буферизация таблицы, которая также создает версию данных у пользователя. Причем в VFP9 эта версия (т.е. еще не сохраненные в таблице данные), кажется, учитывается при запросах, которые этот же клиент строит к редактируемой таблице. Ну, при сохранении данных, конечно, опять же блокировки, как же без них, но в целом поворот в сторону версионника проглядывается.
10 май 05, 20:00    [1527856]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 vadiminfo
Вы же тока сказали, что за МКАДом слабые клиенты.

Я сказал??? Я этого не говорил.
Это местные "самимынеместные" об этом говорят. И одновременно говорят про десяткикилобаксовые сервера.

Делаем вывод: относительно интеллектуальная СУБД туда совсем не влезет.

Влезет блин, влезет. Не читайте сказок на ночь. Или хотя бы смените сказку.

Для этого нужно слово каких-то светил, чей авторитет был общепризнанным на мировом уровне.

А что, моего слова не достаточно? Вах-вах-вах.
Надоть Диченко позвать на помощь.

Воображение, однако. То чего нам с Вами не хватает.

Мне воображения хватает. Я вот только в своем воображении в файл-серверных системах гоняю гигабайты данных по гигабитному эзернету. А КС-сники на это как бычки на красную тряпку бросаются.
10 май 05, 20:05    [1527866]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
А у Тигры так вообще денег на клиентские компутеры не осталось
Как купил сервак за 40000, так с тех пор у него бухгалтера на счетах и считают. И счета-фактуры от руки выписывают, потому что на принтер тоже не хватило.
10 май 05, 20:19    [1527881]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Раз у Вас такое воображение продвинутое, то Вы можете поставть на каждого клента по DB2 (Ораклу или Скулю - интеллектуальное СУБД), а на сервак Аксцесс - как бы он играет роль файл сервера. И выполнять к Серваку удаленные запросы. И посмотреть наскока это хорошо за МКАДом с 3-ми пнями и 32 ОЗУ и 2 - 8Гб жесткий диск. И внутри МКАДа где на IBM eServer p5 595 64p, будет Аксцесс крутиться на все эти большие запросы.
И прикинуть нет ли другого решения.
10 май 05, 20:27    [1527897]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Tygra (Home)
Guest
Я таки повторю кусок из одного вышенаписанного мной поста:

автор
Вообще создается впечатление, что ЛП ни разу нормальных настоящих крупных КС систем не видел, не то что делал их.
Потому разговор продолжать дальше - бессмысленно.
Иначе придется обратиться ко всему миру с предложением отказаться от КС, потому что ЛП знает, как не тратить много денег на большие сервера БД, а сделать все это на ФС, причем работать будет не медленнее КС.


Вот там выделено красным - вы полностью подписываетесь под этим, а ЛП? Вы таки согласны принести щастте в каждую фирму в виде ФС?

===================
Разговор в психиатрической лечебнице напоминает мне этот топик.
Причем не то, что непонятно, кто доктор - это то даже понятно. Доктора просто нет, только санитары Причем кроме санитаров тоже никого больше нет - даже больные давно выздоровили
10 май 05, 20:46    [1527915]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Тигра, ты лучше ответь мне - у тебя деньги на клиентские компутеры остались, или только на сервак хватило?
10 май 05, 20:49    [1527918]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 tygra
Вот там выделено красным - вы полностью подписываетесь под этим, а ЛП? Вы таки согласны принести щастте в каждую фирму в виде ФС?

Что же до меня лично - то свое отношение к ФС я ясно и недвусмысленно высказал еще на первой странице.
Что не мешает мне радоваться и умиляться дибильноватым нападкам на ФС от тебе подобных.
Прикольные долбоёбики, объевшиеся сырого мяса.
10 май 05, 21:05    [1527945]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Я прошу участников дискусии вести себя корректно
10 май 05, 21:15    [1527952]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6884
vadiminfo
Раз у Вас такое воображение продвинутое, то Вы можете поставть на каждого клента по DB2 (Ораклу или Скулю - интеллектуальное СУБД), а на сервак Аксцесс - как бы он играет роль файл сервера. И выполнять к Серваку удаленные запросы. И посмотреть наскока это хорошо за МКАДом с 3-ми пнями и 32 ОЗУ и 2 - 8Гб жесткий диск. И внутри МКАДа где на IBM eServer p5 595 64p, будет Аксцесс крутиться на все эти большие запросы.
И прикинуть нет ли другого решения.

Я так понял, ФС в этой утрированной ситуации - это акцесс, крутящийся на сервере, и отвечающий на обращения клиентов? Гм... Гм... Кхе-кхе... Это не ФС. И Акцесс сам по себе так не умеет. Может, вы зря вообще спорите?

Tygra

...придется обратиться ко всему миру с предложением отказаться от КС, потому что ЛП знает, как не тратить много денег на большие сервера БД, а сделать все это на ФС, причем работать будет не медленнее КС.

В общем случае, если не решать задач типа полнотекстового поиска, ответ на такой общий вопрос можно дать утвердительный. На ФС можно выполнять все функции КС. Только разработка такого проекта займет намного больше времени и потребует гораздо более квалифицированную в среднем команду. И стоить разработка будет намного дороже. И т.д. Да, а на сервере удастся сэкономить. (Прежде, чем кто-нибудь будет отвечать, дескать это патологическая глупость, повторю, самописная под задачу репликация + подготовка данных для критических и частых отчетов заранее, т.е. тщательно продуманная денормализация)
Но ведь это общий случай.
10 май 05, 21:51    [1528006]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Geo

Я так понял, ФС в этой утрированной ситуации - это акцесс, крутящийся на сервере, и отвечающий на обращения клиентов?

Ну как же? На клиенте к примеру Оракл. Он через агента и ODBC видит файл Аксцессной БД на сервере. Мы пишем удаленный запрос SQL для верности с синтаксисом, которого не знает Аксцесс, но знает Оракл. Значит запрос будет выполнен на клиенте? Вроде приближенно к ФС.
Вы называете это утрированной ситуацией? Но если п2 нет, то это должна быть нормальная ситуация с точки зрения распред вычилительных ресурсов и хорошего осчусчения Толстой СУБД на любом клиенте. Отличающаяся от КС тока п3 и условно п1 (ЛП признал его тока условно).
10 май 05, 22:03    [1528026]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
2 vadiminfo : дык п.3 и есть главное отличие, о чём спор?
10 май 05, 22:12    [1528043]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
ЛП

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

четкий признак того, что программеры не умели программировать. Или сервер был бывшим "клиентским", отобранным у секретарши
ЛП

Хотя вы говорите, что ваш двухпроцессорный ксеон равен ста девяносто двум дюронам?

хто-хто ? НАШ двухпроцессорный Ксеон ? Ой мама, держите меня... Поглядели-бы вы на наш Ксеон.
Про 2 сек. писал с чужих слов, просил знакомого
ЛП

Да не надо мне на пальцах

ух как. Я писал, что такие тесты не делал, и выводы мои довольно грубые, но не такие и далекие от реальности.
Кстати, не факт, что 192 компа будет работать медленее, чем аналогичный сервер. Сервер обладает хорошим оптимизатором запросов, и сможет 192 одновременных запроса растусовать наиболее выгодным образом. Опять-же cash hit ratio там будет неслабый и прочая ботва.
Так что может и не 192, а все 200 компов не смогут обогнать
10 май 05, 22:14    [1528045]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alexey Sh

дык п.3 и есть главное отличие, о чём спор?

Это скорее не спор, а обсуждение тех трех пунктов, что в толстой книге прописаны, ну примерно того, чему нас учили. Может действительно некоторые пункты устарели? Вот мы как бы их пытались проверить. Защищать и опровергать. Потому что здесь мы тренируемся, а в реальной практике, возможно, придется реально аргументировать. Поэтому важно знать положение дел со всеми тремя пп сегодня и возможно, что с ними будет завтра.
10 май 05, 22:20    [1528051]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6884
vadiminfo
Вы называете это утрированной ситуацией?

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

vadiminfo
Ну как же? На клиенте к примеру Оракл. Он через агента и ODBC видит файл Аксцессной БД на сервере. Мы пишем удаленный запрос SQL для верности с синтаксисом, которого не знает Аксцесс, но знает Оракл. Значит запрос будет выполнен на клиенте? Вроде приближенно к ФС.

Вы можете написать запрос
select top 1 * from t1 order by id
Его знают и Access (Jet) (Кстати Jet - это ядро акцессовской СУБД, включенное чуть ли не во все виндовс v.>3.11. Это не определение, не потом эту часть буквально цитировать :)), и Oracle.
Но в любом случае клиенту (в аббревиатурах я "плаваю", поэтому ограничусь этим термином) придется тащить к себе все, что ему нужно для выбора этой записи и саму запись. Т.е. какую-то часть первичного ключа и страницу с записью. И запрос исполнять "у себя". Несложно добиться (сложнее добиться обратного), чтоб клиенту в ФС приходилось для выполнения с виду простого запроса, полность прочитать с сервера несколько таблиц и их индексов (для dbf читай: файлов).

Кстати, про страницы: urri был почти прав. Определение Microsoft про MSSQL2000: "Основной единицей хранения данных в SQL Server является страница. В SQL Server 2000 размер страницы составляет 8 кб". В последних версиях Аксесса размер страницы - 4 кб. Поскольку бесполезно читать часть страницы: и в начале, и в конце ее и в MSSQL, и в mdb живет служебная информация, без которой страницу не разобрать по единицам ее содержимого (во всяком случае, это справедливо для страниц с записями таблиц), то меньше, чем по странице читать бесполезно.

Но это я отвлекся. Я хотел сказать, ФС - это не недоразвитый КС. Акцесс для чтения mdb-файла не нужен. ФС - это нечто другое. Упрощая: это файл на диске на одном компьютере, к которому вы пытаетесь обратиться по локальной сети с двух других компьютеров с помощью двух более-менее похожих программ.

Во всяком случае, мне покалось, что вы так считали.
10 май 05, 22:33    [1528061]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
IMHO
Централизованное управление и хранение данных будет всегда лучше и надежнее, чем "доверительное", т.е. где каждое приложение берет на себя соглашения по работе и ответственность за правильность обработки данных. И это главное отличие КС от ФС, все остальное - SQL, минимизация сетевого трафика, даже контроль доступа к данным (авторизация) при желании реализуемы в ФС. Что такое централизованная обработка данных легче всего понимают Access-ники, которых в силу отсутствия в Access полноценного ООП, обделили даже элементарным наследованием форм и заставили по любому так или иначе размазывать логику работы с данными по всему приложению, то то они и радуются триггерам и ХП, когда переходят на КС системы (пример не к тому, что в ФС невозможны триггера).

Лично я за центразованное управление данными, можно сказать "диктатуру", где клиентское приложение еще будет доказывать, что оно где то имеет право читать и чего то изменять :)
10 май 05, 22:55    [1528079]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Yo!!
2Urri
>Что значит, убедил! Требую контраргументов ;-)

раз уж вы считаете деньги, то можно рассказать как вы боритесь:

1.
update bank1 set balance = balance - 2000000 where id=20 ;
update bank2 set balance = balance + 2000000 where id=21 ;

в bank1.dbf все коректно записалось, а вот пока открывался bank2.dbf клиент грузанулся, деньги достаются казино ?

Ну, вообще говоря, легко. Первый способ - без сервера приложений, второй - с.
1. Оформляется транзакция (уж какая ни есть, но это транзакция), во время которой выполняются вышеперечисленные два запроса, но раньше них - для избыточности - такой:
insert into trbank (bank_from,bank_to,delta) values (20,21,2000000) ;
Эта таблица используется при разборе полетов, если что-то пошло не так.
2. Вся эта трехэтажная конструкция заменяется только записью в
insert into trbank (bank_from,bank_to,delta) values (20,21,2000000) ;
, а собственно разноску по bank1 и bank2 выполняет отдельный, выделенный процесс. Который работает с сервера приложений.

2. каждый оператор имеет право переводить деньги со счетов своих клиентов, при этом строго учитывается кто и когда перевел деньги. как защитить dbf чтоб оператор не мог от имени президента переводить бабло куда ему вздумается и зачищать свои следы ?
Ну, насколько я понял, сочетание:
1. Задания путей к БД в виде "\\Server\Share$\MySecretFolder\data.dbf" (простой юзер через проводник ничего не увидит),
2. Наличия пароля к ресурсу, прописанного в программе, а юзеру неизвестного (без некоторых "неюзерских" знаний юзер вообще не получит никакого доступа к файлам),
3. Обязательного журналирования действий пользователя (юзер не сможет перевести бабло так, как это делает программа: он не знает, что существует журнал, а если даже и знает, то не сможет записать в журнал так, как это делает программа, так как предприняты особые меры),
4. Подписки, данной юзерами о том, что ничем подобным заниматься не будут

- не устраивает, то я в ответ спрошу: А что в итоге легче: сломать такую защиту, подобрать пароль президента или подкупить администратора?
3. select sum(bablo), client from bank1 ;
пол файлика скачалось оператору, но тут у него запускается скандиск, из-за этого селект закончится только к утру. как вы отслеживаете все машины в сети чтоб на них не дайбог ничего не запустилось, чтоб остальные не ждали пока секлктик не отпустит блокировки.
Такие селектики либо запускаются с сервера приложений, либо а) запускаются не целиком по всем клиентам, а только по одному и б) не ставят блокировок. Не вижу ничего страшного в том, что sum(bablo) было не совсем точным (тем более, на практике такого практически не бывает). Впрочем, что верно, то верно, тяжелые запросы на ФС идут плохо. Но это повод всего лишь переформулировать задачу, а не отказываться от технологии.
10 май 05, 23:07    [1528090]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Geo
Member

Откуда:
Сообщений: 6884
ASCRUS
то то они и радуются триггерам и ХП, когда переходят на КС системы (пример не к тому, что в ФС невозможны триггера).

2 ASCRUS
Разве у нас не во всех школах учат, что вскрытие больного делается только после смерти? :))
10 май 05, 23:30    [1528102]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
ASCRUS
Централизованное управление и хранение данных будет всегда лучше и надежнее, чем "доверительное", т.е. где каждое приложение берет на себя соглашения по работе и ответственность за правильность обработки данных. И это главное отличие КС от ФС.
Абсолютно согласен.
10 май 05, 23:40    [1528104]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Geo

Я хотел сказать, ФС - это не недоразвитый КС. Акцесс для чтения mdb-файла не нужен. ФС - это нечто другое. Упрощая: это файл на диске на одном компьютере, к которому вы пытаетесь обратиться по локальной сети с двух других компьютеров с помощью двух более-менее похожих программ.



Да все так. И на этом диске лежит файл Аксцесса. И када Аксцесс СУБД на клиенте, и в моем утрированном варианте. Это сервер, где лежит файл в обоих случаях, в основном предоставляет услуги по доступу к файлу. И больше вроде никаких. Мы специально писали непонятный Аксцессу запрос, чтобы убедиться, что нигде не спрятан сам Аксцесс. Или нет?
И к файлу доступают программы с клинта, Оракл, Агент, Ну и прога которая лезет к Ораклу. В случае обычного ФС Прога лезет к Аксцессу, например.
Мне кажется, мы с Вами одинаково понимаем ФС. Тока Вы в моем утрировнном примере находите отличия от ФС, но я не понимаю какие.
Конечно, на это можно взглянуть по другому - распределенная БД с участием как КС СУБД, так ФС. Но роль КС мы постарались свести к нулю.


Geo

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

Я не грил, что это эквивалентно системе, которая состоит из Аксцессов. Но
там еще участвует ODBC - он Аксцессный, и, возможно, что подправит в плане скачиваемого. Однако, кое-что Оракл провернет одним запросом, а на Аксцессе, возможно, и на Вижуалбэйсике придется покропать для того же результата. Я такое применял по неволе - у меня на второй работе Аксцесс, а надо было готовить годовой отчет, и были сложные для структуры БД запросы.
Я прилипился Ораклом к Аксцессной БД - он достаточно шустро все выполнял. Правда там не большие объемы. Кроме того, у нас на основном производстве надо у одного из заказчиков закачивать данные из Аксцесса другого производителя. У другого вообще из Парадокса. Но это вынужденное решение. И там сервак БД. А тут мы на все клиенты его ставим, чтобы с полна почуствовать п2. Толстых СУБД по клиентам распихиваем.

Geo

Кстати, про страницы: urri был почти прав. Определение Microsoft про MSSQL2000: "Основной единицей хранения данных в SQL Server является страница. В SQL Server 2000 размер страницы составляет 8 кб". В последних версиях Аксесса размер страницы - 4 кб. Поскольку бесполезно читать часть страницы: и в начале, и в конце ее и в MSSQL, и в mdb живет служебная информация, без которой страницу не разобрать по единицам ее содержимого (во всяком случае, это справедливо для страниц с записями таблиц), то меньше, чем по странице читать бесполезно.

Ну наверное. У Оракла тоже называется блоками. Они могут быть разными.
10 май 05, 23:46    [1528106]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

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

Все-таки это скорее отличие централизованных БД от распределенных. По крайней мере, в тех терминах, что Вы использовали. Хранение данных у ФС тоже централизованное в случае одного Ф сервера.
10 май 05, 23:55    [1528114]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить