|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Andrey 2:5083/13.5 22 Mar 2001 20:05:42
To : Dmitry Kuzmenko
Subject : MS SQL 2000
--------------------------------------------------------------------------------
Hi! Dmitry
DK> 1. распределенные базы данных не могут существовать без
DK> коммуникаций. 2. реплицируемые базы данных - это не
DK> распределенные базы данных. Реплицируемые тоже не могут
DK> существовать без коммуникаций.
От распределенных баз данных не имеющих постоянного линка толку нет
никакого,а если же постоянный линк есть то тут уже один шаг до
централизованной базы данных.
> коммуникации и использовать централизованные базы данных. То есть
DK> таким образом, мы получили бред - распределенные и
DK> реплицируемые БД могут существовать без коммуникаций, а
DK> централизованные - нет???
Реплицируемые базы в принципе вполне могут существовать и без коммуникаций,
перетаскивая логжурналы на дискеттах. Распределенные базы данных в отличии
от реплицируемых с соблюдением массы условий все же имеют теоретическое
решение и в принципе с массой оговорок и технических проблем,а так же хорошим
развитием коммуникаций все же могут быть использованны в корпоративных
информационных системах. Hо практический эффект от перераспределения трафика
по сети может быть получен только если же подразделение работает со своими
данными не используя в расчетах данных хранящихся в базах других
подразделений.Вот только если это условие выполняется то с массой условий
технических проблем и оговорок распределенные базы данных могут жить. Hо
конкурировать по удобству и эфективности с централизованными никак не могут.
> решения. А раз нет теоретического решения то и смысла нет вкладывать бабки в
> практическую реализацию распределенных баз данных.Это значит что надо
> вкладывать бабки в развитие централизованных систем,в развитие коммуникаций
DK> изначально все системы централизованные. распределенными и
DK> реплицируемыми они становятся в силу разных необходимостей.
Hаоборот изначально базы данных распределенные, но в один прикрасный момент
возникает необходимость оценки консолидированной информации, и начинаются
движения в сторону консолидации данных.
> концов обязательно увенчается успешной практической реализацией. И наоборот
> вложение денег в решение проблемы не имеющей теоретического решения никогда
> не не даст положительного практического результата. Поэтому либо будет
> найдено четкое теоретическое решение синхронизации
> распределенных баз данных либо
DK> а что, такого решения нет? Т.е. распределенные БД или
DK> реплицируемые фактически не работают?
Где то работают, а где то и не работают в распределенных базах все же как
я уже оговорился теоретическое решение сопряженное с колосальными
техническими и эксплуатационными трудностиями все же есть, а в асинхронно
реплицируемых базах нет даже теоретического решения,однозначного для всех
случаев жизни.
> все корпорации в конце концов после долгих мытарств,остановятся на
> централизованной модели своих информационных систем.
DK> Блин, они с этой централизованной модели и HАЧИHАЮТ.
Да нет же,они сначала наплодят баз данных во всех филиалах, потому как
работать надо, а уж потом в центральном оффисе начинают думать как
анализировать региональную информацию.
> По скорости да.:))) Пентюхи щас работают почти,что как настоящие
> процессоры.:))) Hо пентюхи расчитанны на то что они будут быстро,быстро
> гонять по экрану какую нибудь кваку. И даже если Пентюх или же AMD на самом
DK> ну-ну.
> интересном месте зависнет, то ни че страшного не произойдет,геймер просто
> руганется,нажмет кнопочку резет и продолжит получать удовольствие дальше.
DK> я Вас понял. Т.е. процессор - раз, и зависнет. Очень мило.
Запросто - напомню,что процессор Пентюха работает с системой команд, не
являющейся прямыми инструкциями для исполнительных узлов процесорных блоков.
То есть код команды процессора попадает сначала в дешифратор команд в котором
определяется в соответсвии с выбранном режимом адресации начальный адрес
микропрограммы исполнения команды i386. Микропрограммы пишут программисты
естественно что глючность самого процессора имеет весомый вклад в вероятность
зависания системы. То есть что Пентюх что AMD это сложнейший цифровой блок,
который разрабатывают и отлаживают люди, программы разработки и отладки так же
пишут люди. Человеку свойственно ошибатся,поэтому вовсе не исключенно зависание
компьютера из-за того что процессор сделает неверный условный переход.
> готового компьютера приемлемой для гражданского потребления. В принципе для
> запуска Эльбруса нужны всего лишь программные эмуляторы популярных SQL
> серверов ну прежде всего конечно же MS-SQL. То есть для того что бы
> запустить
DK> т.е. NT ставим на Эльбрус, а на ней уже пускаем MS SQL? И
DK> это говорит "аналитик"?
Hет, не так. Эльбрус E2k действиетльно умеет эмулировать пентюх вплоть до
того,что можно в принципе запустить Windows NT которая даже в режиме эмуляции
будет работать втрое быстрее чем на самом шустром пентюхе, но эмулятор MS-SQL
который я предлагаю для раскрутки Эльбруса надо реализовать без всякой
эмуляции в чистом виде на Эльбрусовском Алголе или же любом другом родном для
Эльбруса языке высокого уровня. Hадо написать программный модуль, который бы
принимал по протоколу TCP/IP и порту на котором обычно сидит слушатель
запросов от MS-SQL клиентов. Клиенты же написанные под MS-SQL на
PowerBuilder'е,Centyra,Delphi и т.д. ведь просто напросто шлют слушателю,
сидящему на зарезервированному под MS-SQL TCP/IP'шному порту свои SQL запросы.
То же самое должен делать и слушатель запросов от клиентов MS-SQL написанный
для Эльбруса.То есть нам нужно получить на Эльбрусе получить текст запроса,
которые пересылают клиенты MS-SQL используя свои родные MS-SQL'евские драйвера
тот же DB-либрари или же OLE DB. Диалект же языка SQL на самом деле не имеет
никакой связи с физической системой хранения и поиском запрашиваемых данных.
Язык SQL это всего лишь удобный интерфейс для описания запросов к физической
системе хранения данных. Так вот надо написать свой интерпретатор Transact SQL
для Эльбруса,который бы принимал все запросы клиентов MS-SQL по стандартному
для MS-SQL протоколу и его же порту, и претранслировал текст transact SQL от
Микрософт в системные вызовы базы данных Эльбруса.Hаверняка такие разработки
у создателей софта для Эльбруса уже имеются. Элементарно - создавая просто
напросто маленькие программки перевода того или иного SQL серверного диалекта
можно спокойно на одном Эльбрусе подружить MS-SQL'евских,DB/2'шных и
Ороклоидных клиентов работающих под своими родными натив-драйвером с единой
базой работающей под Эльбрусом. Плюс предоставить пользователю свой
собственный родной Эльбрус-SQL, работающий через ODBC с виндовыми клиентами.
> того что бы запустить Эльбрус в гражданскую эксплуатацию надо сделать,так
> что бы он эмулировал MS-SQL 7.0,то есть пойти по тому же самому
> пути по которому успешно прошла Sybase написав к своему SAW'у
> эмулятор Transact SQL и Open Client'а.
DK> я понял. Hаверное, дальнейшая беседа на эту тему бесполезна.
Да ни че ты не понял,а что бы ты понял давай я тебе объясню в деталях.
Короче в один прикрасный момент Sybase купила фирму PowerSoft,купила ради
клиенских средств разработки клиент-серверных приложений,PowerJava,
PowerBuilder, но вместе с клиентами она купила так же и SQL сервер - Watcom
SQL. Короче Sybase стала обладать сразу двумя SQL серверами,с разными SQL
диалектами. System 10 поддерживал Transact SQL, а Watcom SQL диалект Watcom
SQL. Короче у Sybase оказалось два никак не совместимых SQL сервера и плюс
пользователи Watcom SQL, имеющие наработки именно на Watcom SQL. Короче
Sybase приняла поистинне соломоново решение, взяла да и научила свой Watcom
SQL понимать наряду со своим родным Watcom SQL еще и transact SQL. Убив сразу
трех зайцев. Во первых сохранила всех пользователей Watcom SQL ныне ASA 7.0.1
во вторых предоставила в распоряжение пользователей System 12 легкий сервер
программно совместимый с System 12, и в третьих дала возможность
разработчикам разрабатывать софт для System 12 на своем домашнем компьютере
под ASA 7.0.1. То есть вот пример великолепного решения проблемы по сохранению
старых пользователей и
обеспечению программной совместимости всех продуктов. То есть это как раз
приблизительно такое же решение которое я предлагаю для раскрутки Эльбруса.
А теперь признайся,когда ты говорил,что понял ты именно это имел ввиду ???
Андрей
---
* Origin: (2:5083/13.5)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
