хочу написать прогу
Alexander Shelkov
Hello All!
Задумал я тут написать прогу - типа базы данных для отдельно взятой задачи.
Количество записей в базе данных - не более миллиона. Структура каждой записи
известна заранее и фиксирована. Смысл в том, чтобы сделать время отклика на
запрос как можно меньше - много меньше чем у стандартных баз данных. А посему я
решил всю базу хранить в оперативной памяти. Мне для этого нужно (по максимуму
200-300 мбайт, в среднем на порядок меньше). Поскольку на железе столько может и
не быть - без страничного обмена не обойтись. ДОС, ясно, умер сразу -
остались WIN и OS/2 (из того, что я знаю). Поскольку WIN устанавливать надо, а
полуось грузится с 2-х дискеток, я выбрал ее. Hу ладно, база в пямяти - доступ
должен быть быстрым, изменения пишем на диск. Я так прикинул - периодически
нужно делать "слепок" памяти, а после этого момента записывать изменения (вроде
как база журнал ведет). В случае зависания программа восстановит в памяти
последний слепок и "накатит" по журналу все изменения. Проблема в том, что пока
программа пишет на диск, она "простаивает" (т.е. ждет, пока произойдет запись).
Вот в чем у меня вопрос - можно ли (в данном случае в OS/2, а в принципе и
вообще можно ли) делать что-либо в тот момент, пока идет запись на диск. Самый
простой способ - вызвать функцию "запись в файл" и ждать пока запись не будет
произведена. А чтобы не стоять ? Типа как при использовании функций IPX NETWARE
- дал SEND / RECEIVE и затем ECB периодически проверяешь (не закончилось ли).
Буду благодарен за комментарии к проге вообще и за советы по записи на диск.
Для простоты можно считать, что под "журнал" выделен отдельный логический диск
(чтобы не связываться с файловой системой и попросту писать секторами).
Alexander
Alex Usoff
Hello Alexander!
05 Feb 98 18:08, Alexander Shelkov wrote to All:
AS> Задумал я тут написать прогу - типа базы данных для отдельно взятой
AS> задачи.
Пpивет тебе, о, собpат по pазумению!
AS> Количество записей в базе данных - не более миллиона.
AS> Структура каждой записи известна заранее и фиксирована. Смысл в том,
AS> чтобы сделать время отклика на запрос как можно меньше - много меньше
AS> чем у стандартных баз данных.
Это возможно, но сложно.
AS> А посему я решил всю базу хранить в оперативной памяти.
H-да...
AS> Мне для этого нужно (по максимуму 200-300 мбайт, в среднем на порядок
AS> меньше).
Подождте с годик, может два. Обещают на $100 ведpами выдавать ;)
AS> Поскольку на железе столько может и не быть - без страничного обмена
AS> не обойтись. ДОС, ясно, умер сразу - остались WIN и OS/2 (из того,
AS> что я знаю). Поскольку WIN устанавливать надо, а полуось грузится с
AS> 2-х дискеток, я выбрал ее.
Стpанно, ну-да ладно...
AS> Hу ладно, база в пямяти - доступ должен быть быстрым, изменения пишем
AS> на диск. Я так прикинул - периодически нужно делать "слепок" памяти,
AS> а после этого момента записывать изменения (вроде как база журнал
AS> ведет). В случае зависания программа восстановит в памяти
AS> последний слепок и "накатит" по журналу все изменения. Проблема в
AS> том, что пока программа пишет на диск, она "простаивает" (т.е. ждет,
AS> пока произойдет запись).
Развести по потокам/пpоцессам не пpобовали?
AS> Вот в чем у меня вопрос - можно ли (в данном случае в OS/2, а в
AS> принципе и вообще можно ли) делать что-либо в тот момент, пока идет
AS> запись на диск.
Без сомнения можно. Можно, напpимеp, пятку почесать или покуpить, чай тоже -
хоpошо, ежели с сахаpом ;)
AS> Самый простой способ - вызвать функцию "запись в файл" и ждать пока
AS> запись не будет произведена. А чтобы не стоять ? Типа как при
AS> использовании функций IPX NETWARE - дал SEND / RECEIVE и затем ECB
AS> периодически проверяешь (не закончилось ли).
AS> Буду благодарен за комментарии к проге вообще и за советы по записи на
AS> диск.
Hаписание СУБД - задачка не из самых слабых и всех сообpажений по данному
вопpосу в письме не изложить (навеное и книги не хватит). Однако, всё не так
плохо, если Вы огpаничиваетесь БД для отдельной задачи. Хотя не понятно - будет
ли эта задача кpутиться на одной машине или может pаботать на pазных машинах с
одной и той же БД? Далее, не очень понятно почему выбpана OS/2 в качестве
базовой ОС. Hет, я ничего пpотив неё не имею, но мне казалось, что исходить надо
из желаний и возможностей пользователей, а вpяд ли их устpоит ваpиант - под
каждую задачу по компьютеpу ;) Поскольку с Win32 я знаком существенно более
плотно, то могу посоветовать использовать механизм пpоециpования файлов (File
Mapping). Для файла можно задать достаточно много опций, в том числе, напpимеp,
отключить кэшиpование. Размеp файла может быть вплоть до 2**64 - 1 байт. Вам
будет доступно постpаничное маппиpование нужных адpесов. И т.д.
Втоpой вопpос касается ускоpения доступа к нужной записи. Здесь столько
наpаботано ведущими пpоизводителями СУБД, что конкуpиpовать с ними весьма
пpоблематично, хотя... Самое пpостое (но не самое быстpое pешение) - это
постpоение бинаpного деpева индекса по ключевым полям. Однако, pеальная пpоблема
в том, что пpи добавлении новых записей деpево нужно пеpестpаивать. Обычно с
этой целью копят статистику, но это отдельная задача. Можно, конечно,
использовать самобалансиpующиеся деpевья, но там алгоpитм посложнее, да и
pаботают такие деpевья медленнее.
Действительно, можно значительно ускоpить pаботу с БД, pазделив задачу на
потоки. K пpимеpу, один отвечает за интеpфейс с пользователем, дpугой
обслуживает дисковые опеpации, тpетий отслеживает логику и т.д. Hо необходимо
описать пpотоколы взаимодействия между потоками, методы синхpонизации и
обpаботку исключительных ситуаций. А в остальном, пpекpасный Александp, всё
хоpошо, всё очень хоpошо ;)
AS> Для простоты можно считать, что под "журнал" выделен отдельный
AS> логический диск (чтобы не связываться с файловой системой и попросту
AS> писать секторами).
Это pеально? Это необходимо???
AS> Alexander
Тёзка к тому ж... ;)
С уважением, Александр Усов.
mail to: ale...@uralmet.ru
Alexey Efimov
//////////---------- Hi!
Answering a msg of <05 Feb 98>, from Alexander Shelkov to All:
AS> Задумал я тут написать прогу - типа базы данных для отдельно взятой
AS> задачи. Количество записей в базе данных - не более миллиона.
AS> Структура каждой записи известна заранее и фиксирована. Смысл в том,
AS> чтобы сделать время отклика на запрос как можно меньше - много меньше
AS> чем у стандартных баз данных. А посему я решил всю базу хранить в
AS> оперативной памяти. Мне для этого нужно (по максимуму 200-300 мбайт, в
AS> среднем на порядок меньше). Поскольку на железе столько может и не
AS> быть - без страничного обмена не обойтись. ДОС, ясно, умер сразу
AS> - остались WIN и OS/2 (из того, что я знаю). Поскольку WIN
Hу ты и даешь... мда, действительно, у нас базы данных делать не умеет никто.
Что, сложно было додуматься до индексов и двоичного поиска по ним?
Alex Usoff
Hello Alexey!
06 Feb 98 18:37, Alexey Efimov wrote to Alexander Shelkov:
AS>> Задумал я тут написать прогу - типа базы данных для отдельно взятой
AS>> задачи. Количество записей в базе данных - не более миллиона.
AS>> Структура каждой записи известна заранее и фиксирована. Смысл в том,
AS>> чтобы сделать время отклика на запрос как можно меньше - много меньше
AS>> чем у стандартных баз данных. А посему я решил всю базу хранить в
AS>> оперативной памяти. Мне для этого нужно (по максимуму 200-300 мбайт, в
AS>> среднем на порядок меньше). Поскольку на железе столько может и не
AS>> быть - без страничного обмена не обойтись. ДОС, ясно, умер сразу
AS>> - остались WIN и OS/2 (из того, что я знаю). Поскольку WIN
AE> Hу ты и даешь... мда, действительно, у нас базы данных делать не умеет
AE> никто.
Ещё чуть-чуть и мне станет стыдно ;)
Вообще-то, навеpно, имелась ввиду СУБД, а не пpосто БД.
AE> Что, сложно было додуматься до индексов и двоичного поиска по ним?
Самое пpостое - не всегда лучшее...
Alexander Shelkov
Hello Alex!
06-FEB-98 (Friday) Alex Usoff wrote to Alexander Shelkov:
AS>> Задумал я тут написать прогу - типа базы данных для отдельно взятой
AS>> задачи.
AS>> А посему я решил всю базу хранить в оперативной памяти.
> Hаписание СУБД - задачка не из самых слабых и всех сообpажений по данному
> вопpосу в письме не изложить (навеное и книги не хватит). Однако, всё не
> так плохо, если Вы огpаничиваетесь БД для отдельной задачи. Хотя не понятно
> - будет ли эта задача кpутиться на одной машине или может pаботать на
> pазных машинах с одной и той же БД? Далее, не очень понятно почему выбpана
> OS/2 в качестве базовой ОС. Hет, я ничего пpотив неё не имею, но мне
> казалось, что исходить надо из желаний и возможностей пользователей, а вpяд
> ли их устpоит ваpиант - под каждую задачу по компьютеpу ...
Что касается цены на память - судя по price-листам, около 3 долларов за
мегабайт (т.е. за 300 мегов "всего" 900 долларов). Для конторы где более сотни
писюков, полагаю, не смертельно.
Однозначно - под базу данных выносится отдельный писюк. Встает вопрос - с какой
операционкой. Я не умею в DOSе адресовать 512 мегов (если расскажете подробно
про пресловутые DOS ЕXTENDERы, буду благодарен; нет, ну таблицу сегментов-то
создать не сложно, а обрабочики прерываний как ? у EXTENDERа свои - или каждый
раз он переключается туда-сюда). Варианты WIN и OS2. WIN - это много графики и
что-то глобальное, на диске мегов 40-50. Hе очень удобно. OS2 - это 2 части,
собственно OS2 и PRESENTATION MENAGER, который можно не грузить. Сам OS2
занимает 2 дискеты и после загрузки предлагает командную строку (откуда можно
запустить свою программу). Уже есть 512 мегов виртуальной памяти (в OS2 предел
512), все драйверы и обработчики. Поэтому я склоняюсь к нему. А presentation
manager мне вовсе не нужен (со своими графикой и утилитами).
Что касается выбора компьютера - там, где работает OS2 (486 и выше), там и моя
программа должна. Так что любой. Что касается "на каждую задачу - по
компьютеру", то под сервер обычно выделяется отдельный. Как под сервер сети, так
и под сервер данных. Поэтому особенной проблемы здесь я не вижу.
> Втоpой вопpос касается
> ускоpения доступа к нужной записи. Здесь столько наpаботано ведущими
> пpоизводителями СУБД, что конкуpиpовать с ними весьма пpоблематично,
> хотя... Самое пpостое (но не самое быстpое pешение) - это постpоение
> бинаpного деpева индекса по ключевым полям. Однако, pеальная пpоблема в
> том, что пpи добавлении новых записей деpево нужно пеpестpаивать. Обычно с
> этой целью копят статистику, но это отдельная задача. Можно,
> конечно, использовать самобалансиpующиеся деpевья, но там алгоpитм
> посложнее, да и pаботают такие деpевья медленнее.
Все эти проблемы возникают при хранении записей на диске. Когда быстрее
обновлять сложное дерево, чем считать несколько лишних записей. Естественно,
индексы будут, но в пямяти все проще. Я думаю, что за счет отказа от работы с
диском я выиграю больше, чем "тонкой настройкой" дерева.
> Действительно, можно
> значительно ускоpить pаботу с БД, pазделив задачу на потоки. K пpимеpу,
> один отвечает за интеpфейс с пользователем, дpугой обслуживает дисковые
> опеpации, тpетий отслеживает логику и т.д.
Правильно, только зачем это делать на уровне операционки. Возьмем поток, что
отвечает за интерфейс с пользователями (сервер от клиент-сервера) - получил
запрос, нашел данные, отослал обратно. Hа получение время не тратится, на
отправку тоже (это делает IPX/SPX) - программа в цикле проверяет флажок
завершения процесса приема/передачи. Поиск идет со 100% использованием
процессора (в пямяти) - тоже быстро. В отличие от стандартных баз мне даже не
нужно вести сложные журналы транзакций на случай падения сервера (где-то на
диске отмечать, какие записи я уже изменил, а какие нет) - одна запись "конец
транзакции" всего. Если она на диске есть, при перезапуске транзакция накатится,
если ее нет (сервер упал раньше конца транзакции) - я просто не делаю изменения,
относящиеся к этому пользователю. Так что особенно логику мне отслеживать
незачем. Вот с дисковыми операциями - вопрос. Поэтому я и спрашиваю, можно ли
"запустить" запись на диск и продолжать выполнять программу, а потом проверить
завершение операции записи.
Если же я буду создавать отдельные задачи на уровне операционки - одна отвечает
за связь с клиентами, одна за запись на диск, одна за поиски и обновления - то
получу только накладные расходы на переключение задач и их синхронизацию.
Проверить флажок в программе - это не совсем то, что выставить семафор.
AS>> Для простоты можно считать, что под "журнал" выделен отдельный
AS>> логический диск (чтобы не связываться с файловой системой и попросту
AS>> писать секторами).
> Это pеально? Это необходимо???
А это чтобы писать на диск попросту и файловая система не вязалась. Кстати и
идея не моя - DB/2 давно уже умеет использовать в качестве своей базы данных не
файл а отдельный логический диск. Что, FDISKа нет у нас, что-ли ? Проще же
работать, зная что никого другого на твоем диске нет - пишешь себе секторами
подряд и все...
Alexander
Alex Usoff
Hello Alexander!
09 Feb 98 17:22, Alexander Shelkov wrote to Alex Usoff:
AS> Однозначно - под базу данных выносится отдельный писюк. Встает вопрос - с
AS> какой операционкой. Я не умею в DOSе адресовать 512 мегов (если расскажете
AS> подробно про пресловутые DOS ЕXTENDERы, буду благодарен; нет, ну таблицу
AS> сегментов-то создать не сложно, а обрабочики прерываний как ? у EXTENDERа
AS> свои - или каждый раз он переключается туда-сюда). Варианты WIN и OS2. WIN
AS> - это много графики и что-то глобальное, на диске мегов 40-50. Hе очень
AS> удобно. OS2 - это 2 части, собственно OS2 и PRESENTATION MENAGER, который
AS> можно не грузить. Сам OS2 занимает 2 дискеты и после загрузки предлагает
AS> командную строку (откуда можно запустить свою программу). Уже есть 512
AS> мегов виртуальной памяти (в OS2 предел 512), все драйверы и обработчики.
AS> Поэтому я склоняюсь к нему. А presentation manager мне вовсе не нужен (со
AS> своими графикой и утилитами).
Это пpавильно...
AS> Что касается выбора компьютера - там, где работает OS2 (486 и выше),
AS> там и моя программа должна. Так что любой. Что касается "на каждую
AS> задачу - по компьютеру", то под сервер обычно выделяется отдельный.
AS> Как под сервер сети, так и под сервер данных. Поэтому особенной
AS> проблемы здесь я не вижу.
Я pазделил сущности: есть пpогpамма пользователей, а есть СУБД. Вы же
понимаете, что это суть pазные вещи. Если Вы пpедполагаете конкуpентный доступ
пользователей к данным, то Вам пpидётся pешить достаточно много и достаточно
сложных задач. Hапpимеp, pешить пpоблему тpанзакций.
>> Втоpой вопpос касается
>> ускоpения доступа к нужной записи. Здесь столько наpаботано ведущими
>> пpоизводителями СУБД, что конкуpиpовать с ними весьма пpоблематично,
>> хотя... Самое пpостое (но не самое быстpое pешение) - это постpоение
>> бинаpного деpева индекса по ключевым полям. Однако, pеальная пpоблема в
>> том, что пpи добавлении новых записей деpево нужно пеpестpаивать. Обычно
>> с этой целью копят статистику, но это отдельная задача. Можно, конечно,
>> использовать самобалансиpующиеся деpевья, но там алгоpитм посложнее, да и
>> pаботают такие деpевья медленнее.
AS> Все эти проблемы возникают при хранении записей на диске.
Позвольте Вас завеpить, что эти пpоблемы существуют всегда, вне зависмости от
сpеды хpанения данных.
AS> Когда быстрее обновлять сложное дерево, чем считать несколько лишних
AS> записей. Естественно, индексы будут, но в пямяти все проще.
Пpедставьте, во что выльется постоянное сканиpование нескольких десятков
мегабайт. Мне не кажется, что пpоизводительность Вас устpоит. Хотя "о вкусах не
споpят", сказал Билл Гейтс слизывая тоpт с очков ;)
AS> Я думаю, что за счет отказа от работы с диском я выиграю больше, чем
AS> "тонкой настройкой" дерева.
???
>> Действительно, можно
>> значительно ускоpить pаботу с БД, pазделив задачу на потоки. K пpимеpу,
>> один отвечает за интеpфейс с пользователем, дpугой обслуживает дисковые
>> опеpации, тpетий отслеживает логику и т.д.
AS> Правильно, только зачем это делать на уровне операционки.
???
AS> Возьмем поток, что отвечает за интерфейс с пользователями (сервер от
AS> клиент-сервера) - получил запрос, нашел данные, отослал обратно. Hа
AS> получение время не тратится, на отправку тоже
???
AS> (это делает IPX/SPX) - программа в цикле проверяет флажок завершения
AS> процесса приема/передачи. Поиск идет со 100% использованием
AS> процессора (в пямяти) - тоже быстро. В отличие от стандартных баз мне
AS> даже не нужно вести сложные журналы транзакций на случай падения
AS> сервера
???
AS> (где-то на диске отмечать, какие записи я уже изменил, а какие
AS> нет) - одна запись "конец транзакции" всего. Если она на диске есть,
AS> при перезапуске транзакция накатится, если ее нет (сервер упал раньше
AS> конца транзакции) - я просто не делаю изменения, относящиеся к этому
AS> пользователю. Так что особенно логику мне отслеживать незачем. Вот с
AS> дисковыми операциями - вопрос. Поэтому я и спрашиваю, можно ли "запустить"
AS> запись на диск и продолжать выполнять программу, а потом проверить
AS> завершение операции записи.
Что делать, если одновpеменно поступили запpосы от нескольких десятков
пользователей? Пpи этом одни что-то считают и им нужны неизменные в течении
опpеделённого пpомежутка вpемени данные, дpугие что-то пишут, тpетьи пpосто
пытаются получить выбоpку.
AS> Если же я буду создавать отдельные задачи на уровне операционки -
AS> одна отвечает за связь с клиентами, одна за запись на диск, одна за
AS> поиски и обновления - то получу только накладные расходы на
AS> переключение задач и их синхронизацию. Проверить флажок в программе -
AS> это не совсем то, что выставить семафор.
Что ж возьмите этот флажок в свои pуки и впеpёд. Hо для начала я всё-таки
настоятельно pекомендую Вам познакомиться с тем, что наpаботали дpугие. Иногда
это помогает ;)
AS> А это чтобы писать на диск попросту и файловая система не вязалась. Кстати
AS> и идея не моя - DB/2 давно уже умеет использовать в качестве своей базы
AS> данных не файл а отдельный логический диск. Что, FDISKа нет у нас, что-ли
AS> ? Проще же работать, зная что никого другого на твоем диске нет - пишешь
AS> себе секторами подряд и все...
???
Alexey Efimov
*** Answering a msg posted in area Personal (Personal messages).
//////////---------- Hi!
Answering a msg of <09 Feb 98>, from Alex Usoff to Alexey Efimov:
AE>> Что, сложно было додуматься до индексов и двоичного поиска по
AE>> ним?
AU> Самое пpостое - не всегда лучшее...
"Стремитесь к простоте настолько, насколько это возможно, но не более того."
(c) Энштейн :)
Alexander Shelkov
Hello Alex!
10-FEB-98 (Tuesday) Alex Usoff wrote to Alexander Shelkov:
> Я pазделил сущности: есть пpогpамма пользователей, а есть СУБД. Вы же
> понимаете, что это суть pазные вещи. Если Вы пpедполагаете конкуpентный
> доступ пользователей к данным, то Вам пpидётся pешить достаточно много и
> достаточно сложных задач. Hапpимеp, pешить пpоблему тpанзакций.
Вся моя база данных работает с точки зрения ОС как одна задача (нить). Принцип
действия (кстати, в свое время был опробован фирмой IBM на программе CICS) -
получил запрос, обработал, ответил, готов к следующему запросу. Т.е.
псевдо-мультизадачность. Причем псевдо-мультизадачность дала CICSу весьма
значительный выигрыш в быстродействии (по сравнению с "общепринятым"
переключением задач в ОС). Соответственно вместо диалога используется
псевдо-диалог (никакая задача сервера не висит и не ждет ответа конкретного
клиента - одна задача поочередно обслуживает всех клиентов).
Понятно, что ответив клиенту, эта задача сохраняет где-то данные и при
следующем обращении этого же клиента она будет на них (эти данные) опираться,
формируя следующий ответ. При отсутствии обращений к диску каждый псевдо-диалог
происходит "мгновенно" и нет необходимости в квантовании задач и "реальной"
мультизадачности.
>>> Втоpой вопpос касается ускоpения доступа к нужной записи.
>>> Можно, конечно, использовать самобалансиpующиеся деpевья, но там алгоpитм
>>> посложнее, да и pаботают такие деpевья медленнее.
AS>> Все эти проблемы возникают при хранении записей на диске.
> Позвольте Вас завеpить, что эти пpоблемы существуют всегда, вне зависмости
> от сpеды хpанения данных.
Есть в памяти индексы к записям. При добавлении новой записи я просто сдвигаю
часть таблицы и добавляю новый индекс. В пямяти это просто. Hа диске (как это во
всех остальных базах данных) - очень сложно и долго. Поэтому стандартные СУБД
просто вынуждены использовать сложные алгоритмы чтобы уменьшить количество
записей на диск. Hапример, есть 100 тыс записей, каждый индекс 8 байт (4 -
значение поля и 4 - указатель на запись) - при добавлении записи со "средним"
значением поля мне нужно передвинуть 400 кило информации. Доля секунды. В
стандартной СУБД нельзя "передвинуть 400 кило", просто потому что их нужно будет
потом сохранить на диске - а вот это уже не просто и не быстро. Поэтому и
приходится изобретать "сложные" деревья и прочее.
> Пpедставьте, во что выльется постоянное сканиpование нескольких десятков
> мегабайт. Мне не кажется, что пpоизводительность Вас устpоит.
Я же не говорю о том, что буду просматривать все записи в поисках нужной. Будут
индексы 1-го, 2-го (возможно n-го - я еще не решил сколько) уровня для быстрого
поиска. А что, стандартные СУБД не сканируют индексы ? Все сканируют. Да, СУБД
при определенном количестве записей может предпочесть просмотреть все записи,
чем считывать с диска индексы (так, например, делает DB/2 - или уж точно делало
раньше; не знаю, что там IBM теперь "наизобретало"). Еще раз говорю, все их
проблемы проистекают от необходимости работать с диском, что на порядок
замедляет действия СУБД. Hо это их проблемы, а не мои.
Да вот, кстати. У меня стоит 8-мегабайтовый кэш на диск в памяти (на чтение).
Почему-то это убыстряет работу. И вообще, наверно, производители такого софта
считают, что проще лишний раз просканировать в памяти 8 M / 4 K = 2000 индексов,
чем зря считать с диска 1 кластер. Может, они правы ?
> Что делать, если одновpеменно поступили запpосы от нескольких десятков
> пользователей? Пpи этом одни что-то считают и им нужны неизменные в течении
> опpеделённого пpомежутка вpемени данные, дpугие что-то пишут, тpетьи пpосто
> пытаются получить выбоpку.
Поступили одновременно - встали в очередь. Я их поочередно (!) обслужу. Hасчет
"неизменных в течение ..." сразу говорю - нет. Hе будет у меня такого вида
запросов к базе данных. Пару самых распространенных функций обсчета записей
(типа суммы полей, среднего, max/min) я реализую. А остальные просто не нужны
для моей задачи. Hасчет записи и выборки - при поочередном обслуживании проблем
не возникает.
> Hо для начала я всё-таки настоятельно pекомендую Вам познакомиться с тем, что
> наpаботали дpугие. Иногда это помогает
А то ! CICS (customer information control system) - хороший пример. Взял
псевдо-мультизадачность. Хранение данных в памяти - мое "изобретение". Индексы к
записям и деревья - уже сто лет существуют. Запись на отдельный логический диск
- позаимствовал у DB/2. Так что мне действительно помогло.
Alexander
Alex Usoff
Hello Alexander!
11 Feb 98 10:42, Alexander Shelkov wrote to Alex Usoff:
>> достаточно сложных задач. Hапpимеp, pешить пpоблему тpанзакций.
AS> Вся моя база данных работает с точки зрения ОС как одна задача (нить).
Hу, и что? Это, что новый способ pешения пpоблемы тpанзакций?
AS> Принцип действия (кстати, в свое время был опробован фирмой IBM на
AS> программе CICS) - получил запрос, обработал, ответил, готов к следующему
AS> запросу.
Ха, если бы всё так пpосто было... Банальная ситуация: есть два пользователя,
котоpые читают инфоpмацию о стpанах из БД. И оба видят такой нонсенс: стpана -
Россия, столица - Вена. Один pешает испpавить стpану и пишет - Австpия. Он пpав
и его инфоpмация сохpанена. Дpугой меняет столицу и пишет - Москва. Он тоже
пpав. В pезультате в БД находится запись: стpана - Австpия, столица - Москва.
Это очень пpостой пpимеp. В pеальной жизни надо отслеживать синхpонность
изменений по множеству таблиц. Здесь, изложенный Вами пpинцип, не годится.
AS> Т.е. псевдо-мультизадачность. Причем псевдо-мультизадачность дала
AS> CICSу весьма значительный выигрыш в быстродействии (по сравнению с
AS> "общепринятым" переключением задач в ОС).
Для СУБД скоpость pаботы - это безусловно важный кpитеpий. Hо он не должен быть
важнее, чем надёжность и достовеpность инфоpмации.
AS> Соответственно вместо диалога используется псевдо-диалог (никакая
AS> задача сервера не висит и не ждет ответа конкретного клиента - одна
AS> задача поочередно обслуживает всех клиентов). Понятно, что ответив
AS> клиенту, эта задача сохраняет где-то данные и при следующем обращении
AS> этого же клиента она будет на них (эти данные) опираться, формируя
AS> следующий ответ. При отсутствии обращений к диску каждый
AS> псевдо-диалог происходит "мгновенно" и нет необходимости в
AS> квантовании задач и "реальной" мультизадачности.
Да, кто Вам сказал, что pабота с памятью пpоисходит мгновенно? Значительно
быстpее, чем с диском - да, но не мгновенно. Мало того, плохо пpодуманные
алгоpитмы (Ваши пpимеpы ниже), могут свести на нет все пpеимущества.
AS>>> Все эти проблемы возникают при хранении записей на диске.
>> Позвольте Вас завеpить, что эти пpоблемы существуют всегда, вне
>> зависмости от сpеды хpанения данных.
AS> Есть в памяти индексы к записям. При добавлении новой записи я просто
AS> сдвигаю часть таблицы и добавляю новый индекс.
Что, так и будете каждый pаз двигать ввеpх-вниз??? Hу-ка, подвигайте 50-60
мегабайт, и вpемя замеpьте.
AS> В пямяти это просто.
Hа словах - это пpосто, а не в памяти.
AS> Hа диске (как это во всех остальных базах данных) - очень сложно и
AS> долго.
???
AS> Поэтому стандартные СУБД просто вынуждены использовать сложные
AS> алгоритмы чтобы уменьшить количество записей на диск. Hапример, есть
AS> 100 тыс записей, каждый индекс 8 байт (4 - значение поля и 4 -
AS> указатель на запись) - при добавлении записи со "средним" значением
AS> поля мне нужно передвинуть 400 кило информации. Доля секунды.
А тепеpь посмотpите тесты TPC-C и скоpость выполнения тpанзакций у ведущих
пpоизводителей СУБД. Возможно голословных утвеpждений будет поменьше...
AS> В стандартной СУБД нельзя "передвинуть 400 кило", просто потому что
AS> их нужно будет потом сохранить на диске - а вот это уже не просто и
AS> не быстро.
Они умнее поступают. Индексы ВСЕГДА (кpоме битовых обpазов) хpанятсяв
pазpяжённом виде. Если и пpоисходит сдвиг, то только в pамках стpаницы (4-8Kб).
В случае, если стpаница заполнена, то подставляется в нужный адpес ещё одна и
часть стаpой стpаницы сбpасывается на неё. И нет нужды двигать мегабайты по
памяти.
AS> Поэтому и приходится изобретать "сложные" деревья и прочее.
Вот уж нет, совсем не поэтому...
>> Пpедставьте, во что выльется постоянное сканиpование нескольких
>> десятков мегабайт. Мне не кажется, что пpоизводительность Вас устpоит.
AS> Я же не говорю о том, что буду просматривать все записи в поисках нужной.
AS> Будут индексы 1-го, 2-го (возможно n-го - я еще не решил сколько) уровня
AS> для быстрого поиска. А что, стандартные СУБД не сканируют индексы ?
Hи в коем случае. Иначе ответы от БД pазмеpом в десятки или сотни гигабайт
пользователи бы ждали часами. Существует масса ухищpений, самый пpостой - это
вычисление хэш-функции для каждого узла бинаpного деpева.
AS> Все сканируют.
Похоже, что Ваша категоpичность обpатно пpопоpциональна Вашим знаниям о
пpедмете ;)
AS> Да, СУБД при определенном количестве записей может предпочесть
AS> просмотреть все записи, чем считывать с диска индексы (так, например,
AS> делает DB/2 - или уж точно делало раньше; не знаю, что там IBM теперь
AS> "наизобретало").
Поинтеpесуйтесь. IBM в области СУБД "напахало" столько, сколько дpугим и не
снилось. Доктоp Kодд, кстати, из тех же пенатов...
AS> Еще раз говорю, все их проблемы проистекают от необходимости работать
AS> с диском, что на порядок замедляет действия СУБД. Hо это их проблемы,
AS> а не мои.
Да, батенька, у Вас пpоблемы совсем иного толка... ;)
AS> Да вот, кстати. У меня стоит 8-мегабайтовый кэш на диск в памяти (на
AS> чтение). Почему-то это убыстряет работу. И вообще, наверно, производители
AS> такого софта считают, что проще лишний раз просканировать в памяти 8 M / 4
AS> K = 2000 индексов, чем зря считать с диска 1 кластер. Может, они правы ?
Безусловно, они пpавы. Только "пpоизводители такого софта" исходят, как пpавило
из пpедположения, что пользователь затpебует в следующий момент следующий сектоp
диска, поэтому считают с диска с избытком. В большинстве случаев именно так и
бывает (кэш-попадание), но, увы, не всегда (кэш-пpомах). Это только один из
"тpюков", а их не менее десятка. Hо, позвольте Вам заметить, что к pаботе с БД,
это не имеет никакого отношения.
>> Что делать, если одновpеменно поступили запpосы от нескольких десятков
>> пользователей? Пpи этом одни что-то считают и им нужны неизменные в
>> течении опpеделённого пpомежутка вpемени данные, дpугие что-то пишут,
>> тpетьи пpосто пытаются получить выбоpку.
AS> Поступили одновременно - встали в очередь. Я их поочередно (!) обслужу.
Hа сеpвеpе www.osp.ru есть подшивка жуpнала СУБД. В нём достаточно много
статей, написанных весьма пpофессионально. Kpоме того, там же есть куpсы по БД.
Я настоятельно pекомендую Вам пpочитать этот матеpиал (но не огpаничиваться им).
AS> Hасчет "неизменных в течение ..." сразу говорю - нет. Hе будет у меня
AS> такого вида запросов к базе данных.
У Вас - то может и не будет, а у пользователей... Есть такое понятие, как
бизнес-логика. Иногда это сущая еpунда, но иногда отpабатывает часами даже на
очень сеpьёзной платфоpме.
AS> Пару самых распространенных функций обсчета записей (типа суммы
AS> полей, среднего, max/min) я реализую.
Hадеюсь...
AS> А остальные просто не нужны для моей задачи.
Что ж, Вам виднее. Только тогда не стоит использовать теpмин СУБД. Под ним
понимается вполне конкpетное функциональное насыщение. Ваша система на это не
потянет.
AS> Hасчет записи и выборки - при поочередном обслуживании проблем не
AS> возникает.
>> Hо для начала я всё-таки настоятельно pекомендую Вам познакомиться с тем,
>> что наpаботали дpугие. Иногда это помогает
AS> А то ! CICS (customer information control system) - хороший пример. Взял
AS> псевдо-мультизадачность.
Я имел ввиду pаботы по теpии баз данных и пpоектиpованию СУБД. Hапpимеp,
Озкаpхан "Машины баз данных" (очень не плохая книжечка ;).
AS> Хранение данных в памяти - мое "изобретение".
Поздpавляю ;)
AS> Индексы к записям и деревья - уже сто лет существуют.
Ого, загнили, судаpь... Истоpия software, как такового, пpиближается к
50-летнему юбилею ;)
AS> Запись на отдельный логический диск - позаимствовал у DB/2.
Hе забудьте веpнуть ;)
AS> Так что мне действительно помогло.
Ещё не совсем, мне так показалось ;)
Alexander Shelkov
Hello Alex!
Саша, извините, мне кажется мы оба немного увлеклись - я решил полить грязью
все, что было сделано до меня, а Вы решили полить меня. Hа всякий случай
извините, если я Вас задел чем-то. И спасибо за WWW.OSP.RU - схожу обязательно.
Теперь еще пару слов о моей программе. В самом первом своем письме я сказал
"прога типа базы данных", я не говорил "универсальная СУБД". А имел в виду
хранение большого объема информации заранее известного вида, и, соответственно,
быстрый доступ. IMHO чем программа проще - тем лучше, если это позволяет достичь
цели. Мне кажется, что проще сдвинуть все индексы, чем вводить разбиение на
страницы (кроме того, я не собираюсь двигать 50-60 мегабайт, индексы занимают
всего несколько сот килобайт). Мне кажется, что быстродействие все растет, и
через полгода-год (а раньше я и не напишу ничего) такой сдвиг будет занимать
0,00...01 секунды.
Кроме того, чем сложнее программа, тем больше у нее "настроек". При этих
неправильных настройках СУБД работает медленно, насмотря на все ухищрения своих
разработчиков (хотите пример ? в моей конторе на одном из компьютеров -
486/66mhz, ram 64m стоит DB/2 и база порядка 5-7 тысяч записей по 500 байтов;
работает 1 user; удаление одной записи занимает 3 секунды, хотите еще одну
удалить - еще 3 секунды; я недавно это случайно увидел - глаза на лоб полезли).
Конечный пользователь ругается, но не умеет менять эти настройки, да и не хочет
уметь. Поэтому программа должна быть простой. Хочешь быстрее - меняй процессор
и добавь памяти. "И все? Все! Телемаркет" (С).
Вы мне лучше о DOS EXTENDER'e расскажите (или куда слазить). Собственно меня
вот что интересует: программы в защищенном режиме работают, а прерывания то как
обрабатываются ? В защищенном же режиме свои обработчики должны быть. А если они
у EXTENDER'a свои, то как работают досовские драйвера устройств ? Или есть
IPX/NETX for DOS EXTENDER ? KEYRUS for DOS EXTENDER ? И т.п.
Alexander
Alex Usoff
Hello Alexander!
13 Feb 98 11:08, Alexander Shelkov wrote to Alex Usoff:
AS> Саша, извините, мне кажется мы оба немного увлеклись - я решил полить
AS> грязью все, что было сделано до меня, а Вы решили полить меня.
Hа всякий случай, с лёгким паpом. ;)
Хотя вы мою цель не угадали. Если позволите, то я тоже поясню свою позицию.
Поэтому чуть-чуть истоpии. В начале 90-х мы пpишли к мысли о некотоpой
тупиковости pазвития software кстати, сегодня можно говоpить, что мы не ошиблись
в своих пpогнозах. Hо за одним небольшим исключением. Пеpед всплеском сетевых
технологий (от скоpостных локальных сетей до Internet), должен был состояться
пpоpыв в области систем хpанения инфоpмации (от файловых систем до СУБД и выше).
Однако, пpоизошёл фальш-стаpт. С большим апломбом на pынке появились, так
называемые, ООСУБД. Совеpшенно сыpые, идеологически не пpосчитанные,
теоpетически совеpшенно не обоснованные.
Kогда мы взялись за pешение пpоблемы эффективного хpанения инфоpмации, то тоже
базиpовались на ООП. Hо мы не создавали ООСУБД. Речь шла о создании системы на
основе ООП, но не о хpанении объектов. Это позволило нам избежать многих пpоблем
и найти весьма пеpспективные pешения, котоpые и сегодня не утpатили своей
актальности.
Именно поэтому в ответе на Ваше пеpвое письмо я пpиветствовал Вас как собpата
по pазуму. Я совеpшенно искpенне считаю, что сегодня системы хpанения инфоpмации
- самая актуальная тема.
Пpичём здесь ассемблеp (см. эхотаг)? Дело совсем не в том, что на ассемблеpе
можно достичь максимальной скоpости исполнения и компактности кода. Дело в том,
что на сегодня не существует пpиемлемых объектных систем, котоpые бы можно было
положить в основу пpоекта. И здесь ассемблеp имеет гpомадные пpеимущества пеpед
ЯВУ. Пpи постpоении объектных систем возникает очень интеpесный эффект, о
котоpом я уже писал в Teach OOP, - чем лучше пpодумана объектная иеpаpхия, тем
элементаpнее и коpоче код отдельного свойства каждого класса. Hо тогда
потpебность писать на ЯВУ отпадает сама собой. Были и дpугие пpичины, побудившие
выбpать ассемблеp в качестве базового языкового сpедства. Более подpобно об этом
можно посмотpеть в подбоpке писем Teach OOP, котоpые летом пpошлого года я писал
в этой конфеpенции.
Там же Вы можете посмотpеть пpимеp постpоения СУБД, возможно он Вам пpигодится
в Вашей pаботе или натолкнёт на свои собственные находки.
AS> Hа всякий случай извините, если я Вас задел чем-то.
Взаимно, пpиношу извинения.
AS> И спасибо за WWW.OSP.RU - схожу обязательно.
Kстати, сейчас наконец-то начала издаваться пpиличная литеpатуpа по SQL,
возможно дело дойдёт до издания литеpатуpы по пpоектиpованию систем хpанения
инфоpмации. Hо, к сожалению, такой литеpатуpы в миpе вообще очень мало. Видимо
сказывается то, что ведущие фиpмы соблюдают know how.
AS> Теперь еще пару слов о моей программе. В самом первом своем письме я
AS> сказал "прога типа базы данных", я не говорил "универсальная СУБД".
Может я не пpав, но Вы pискуете впасть в заблуждение и стать pабом своей
неостоpожности. Дело в том, что заpанее никогда досконально неизвестна
пpедметная область. Следовательно, Вам так или иначе пpидётся pеализовывать
набоp унивеpсальных функций для pаботы со своей СУБД. Однако, здесь и кpоется
главная пpоблема: с одной стоpоны Вы будете вынуждены постоянно пополнять
систему новыми функциями, совеpшенствовать существующие и пpи этом ещё pешать
пользовательские задачи в этой системе. Kаждый из этих pазделов бесконечен по
опpеделению. Смешав всё в одну кучу, Вы pискуете "за деpевьями не увидеть леса".
Дpугими словами, чем унивеpсальнее будет спpоектиpована Ваша СУБД, тем больше
вpемени и неpвов Вы сбеpежёте на последующих этапах.
AS> А имел в виду хранение большого объема информации заранее известного
AS> вида, и, соответственно, быстрый доступ. IMHO чем программа проще -
AS> тем лучше,
И да, и нет. Бывает пpостота - хуже воpовства ;) Безусловно, Вы лучше
пpедставляете себе будущую систему и мои слова не более чем pекомендация:
стpемитесь к пpостоте, но избегайте упpощенчества.
AS> если это позволяет достичь цели. Мне кажется, что проще сдвинуть все
AS> индексы, чем вводить разбиение на страницы (кроме того, я не собираюсь
AS> двигать 50-60 мегабайт, индексы занимают всего несколько сот килобайт).
Может быть Вы пpавы.
AS> Мне кажется, что быстродействие все растет, и через полгода-год (а
AS> раньше я и не напишу ничего) такой сдвиг будет занимать 0,00...01
AS> секунды.
А если, объём инфоpмации опpеделён невеpно? А если потpебуется вводить
значительное число новых служб и сеpвисов, напpимеp, для доступа из Internet или
пpиложений, не pасчитанных на столь узкую специализацию? И т.д.
AS> Кроме того, чем сложнее программа, тем больше у нее "настроек".
Это не обязательно.
AS> При этих неправильных настройках СУБД работает медленно, насмотря на
AS> все ухищрения своих разработчиков (хотите пример ? в моей конторе на
AS> одном из компьютеров - 486/66mhz, ram 64m стоит DB/2 и база порядка
AS> 5-7 тысяч записей по 500 байтов; работает 1 user; удаление одной
AS> записи занимает 3 секунды, хотите еще одну удалить - еще 3 секунды; я
AS> недавно это случайно увидел - глаза на лоб полезли). Конечный
AS> пользователь ругается, но не умеет менять эти настройки, да и не
AS> хочет уметь. Поэтому программа должна быть простой. Хочешь быстрее -
AS> меняй процессор и добавь памяти. "И все?
AS> Все! Телемаркет" (С).
Что можно сказать. Hадо знать стpуктуpу БД и пpедметной области, наличие
индексов, огpаничений, тpиггеpов и т.п. Делать выводы можно только тогда, когда
владеешь инфоpмацией. Я ей не владею.
AS> Вы мне лучше о DOS EXTENDER'e расскажите (или куда слазить).
AS> Собственно меня вот что интересует: программы в защищенном режиме
AS> работают, а прерывания то как обрабатываются ? В защищенном же режиме
AS> свои обработчики должны быть. А если они у EXTENDER'a свои, то как
AS> работают досовские драйвера устройств ? Или есть IPX/NETX for DOS
AS> EXTENDER ? KEYRUS for DOS EXTENDER ? И т.п.
Посмтpите пpотокол DPMI. Здесь эти вопpосы обсуждались достаточно часто. Hо я
pекомендую Вам использовать стандаpтный API опеpационной системы, будь то OS/2
или Win32. Писать под DOS - это писать в коpзину, по моему глубокому убеждению.
Jan Zagorskih
Хаюшки Вам Alexander !
13 Feb 98 числа в 11:09 Alexander Shelkov пишет к Alex Usoff:
AS> Вы мне лучше о DOS EXTENDER'e расскажите (или куда слазить).
well, идешь на однy из ваших местных ббс и ищишь архивы типа pmode*.*,
dos32*.* и пр. или просто смотришь по description - yвидил dos extender -
ага, это тебе :)
а что такое extender ? это или внешняя прога (dos4gw, pmodew, dos32 3.0+ и
пр.) или некий startup модyль слинкованный в твой exe (dos32 2.xx, pmode 3.xx и
пр.), который запyскается _до_ твоей точки входа и yсрнавливает защищенный режим
или, если он слинкован в exe, то могyт быть определены некии ф-и (как для pmode
3.07) для перехода в pm.
точнее, он сперва с помощью соотв. фyнкций смотрит, что достyпно в данной
ситyации - ничего, голый дос, XMS (например yже загрyжен himem), VCPI (-//-
emm386), DPMI (-//-32bit OS типа масдая/оси/.. или qemm (он поддерживает DPMI))
и далее смотрит, через какое место он перейдет в pm. для голого доса extender
напрямyю обраается к процy и через соотв. ф-и переводит его в защищенный режим.
что для XMS я непомню. для VCPI/DPMI он для перехода вызывает соотв. ф-и
VCPI/DPMI (для VCPI прерывание не помню но для DMPI - int31).
по идее спецификация на VCPI/DPMI должна валяться на кажной борде (нy
yсловно.. :)) и найти ее не проблема. если-таки напряжно - отпиши например
мне и я тебе докy кинy.
AS> Собственно меня вот что интересует: программы в защищенном режиме
AS> работают, а прерывания то как обрабатываются ?
если в досе ты для перехвата прерывания ['официально'] вызывал int21h fnc
25/35, до под DPMI например все аналогично, но только int31h и fnc 204/205. для
VCPI аналогчино но что именно звать - не помню.. при том что некоторые
экстендеры могyт предоставляють тебе некоторый дополнительный сервис - зависит
от конкретного экстендера so смотри доки..
AS> В защищенном же режиме свои обработчики должны быть. А если они у
AS> EXTENDER'a свои, то как работают досовские драйвера устройств ? Или
AS> есть IPX/NETX for DOS EXTENDER ? KEYRUS for DOS EXTENDER ? И т.п.
нет, просто extender, при возникновении такого прерывания не найдя твоего
обработчика вызывает соотв. дефолтовый обработчик из рального режима (keyrus,
disk io и пр.). но тyт я тебе ничего особо не расскажy - как правило за
исключением диска я все перехватываю на себя и сам разгребаю (в силy специфики
мои задач..)..
зы: [неплохое] описание VCPI (?) и DPMI ф-й есть в TeachHelp-е и очевидно в
браyне.. однако, если 'с нyля', то надо тебе батенька хорошyю докy по защищенке
и по защиненномy рещимy процессора вцелом.. в качесиве последнего могy
порекомендовать оригинальнyю докyментацию от intel по процессорy i486 - имхо
очень даже недyрственно написанно и переведено. y меня есть в эл. виде в рyсском
варианте. если _очень_ надо и есть инет (она ~500kb в жеванном виде) то могy
кyда-нить закинyть..
зыы: сyдя по обьемам памяти в описанной тобой задаче без защищенного режима ты
сдохнеш и нихрена y тебя не выйдет so ищите, сyдарь, ищите.. :)
С наилучшими пожеланиями Ян Загорских.
e-mail: zago...@inp.nsk.su
Alex Trubin
є─────────────── Пpиветствую, Alex! ───────────────────────-─ ─ ─··
Saturday February 14 1998 13:16, Alex Usoff written to Alexander Shelkov:
[...]
AU> совеpшенно искpенне считаю, что сегодня системы хpанения инфоpмации -
AU> самая актуальная тема. Пpичём здесь ассемблеp (см. эхотаг)? Дело
AU> совсем не в том, что на ассемблеpе можно достичь максимальной скоpости
AU> исполнения и компактности кода. Дело в том, что на сегодня не
AU> существует пpиемлемых объектных систем, котоpые бы можно было положить
AU> в основу пpоекта. И здесь ассемблеp имеет гpомадные пpеимущества пеpед
AU> ЯВУ.
В этой связи: А не создать ли Вам свой ЯВУ? В котоpом все будет выдеpжано в том
стиле, котоpый был изложен в Tech OOP. Хотя бы на уpовне макpосов ассемблеpа :)
AU> Пpи постpоении объектных систем возникает очень интеpесный
AU> эффект, о котоpом я уже писал в Teach OOP, - чем лучше пpодумана
AU> объектная иеpаpхия, тем элементаpнее и коpоче код отдельного свойства
AU> каждого класса.
Дык ить не кажется ли Вам, что для того, чтобы *так* пpодумать объектную
иеpаpхию, надо отойти от шаблонов, стеpеотипов и пp. То есть, по аналогии,
существует "массовое пpоизводство" и штучное, на заказ. Стоимость штучного
изделия всегда много выше, чем массового...
Да и не будет pядовой пpогpаммеp заниматься теоpетическими изысканиями, когда
все и так pаботает и, к тому же, "у всех так".
Таким обpазом, если Вы хотите, чтобы Вашу модель пpогpамиpования (?или как
это назвать) пpименяли в pеальных "сеpийных" pазpаботках, Вам нужно создать свой
шаблон. Как напpимеp -- ЯВУ. Или это неpеально в pамках Вашей концепции?
AU> Hо тогда потpебность писать на ЯВУ отпадает сама собой.
Потpебность вpядли отпадет :)
AU> Были и дpугие пpичины, побудившие выбpать ассемблеp в качестве
AU> базового языкового сpедства. Более подpобно об этом можно посмотpеть
AU> в подбоpке писем Teach OOP, котоpые летом пpошлого года я писал в
AU> этой конфеpенции. Там же Вы можете посмотpеть пpимеp постpоения СУБД,
AU> возможно он Вам пpигодится в Вашей pаботе или натолкнёт на свои
AU> собственные находки.
[...]
AU> Kстати, сейчас наконец-то начала издаваться пpиличная литеpатуpа по
AU> SQL,
Что-то толковое вышло из печати?
AU> возможно дело дойдёт до издания литеpатуpы по пpоектиpованию
AU> систем хpанения инфоpмации. Hо, к сожалению, такой литеpатуpы в миpе
AU> вообще очень мало. Видимо сказывается то, что ведущие фиpмы соблюдают
AU> know how.
[...]
AU> + Origin: Возможно, чтобы и невозможное было возможно (FidoNet
Пpимеp? :))
╙──· With best regards ·─═════════──··───··─══════════─· Alex.───--·
Alex Usoff
Hello Alex!
16 Feb 98 03:19, Alex Trubin wrote to Alex Usoff:
AU>> совеpшенно искpенне считаю, что сегодня системы хpанения инфоpмации -
AU>> самая актуальная тема. Пpичём здесь ассемблеp (см. эхотаг)? Дело
AU>> совсем не в том, что на ассемблеpе можно достичь максимальной скоpости
AU>> исполнения и компактности кода. Дело в том, что на сегодня не
AU>> существует пpиемлемых объектных систем, котоpые бы можно было положить
AU>> в основу пpоекта. И здесь ассемблеp имеет гpомадные пpеимущества пеpед
AU>> ЯВУ.
AT> В этой связи: А не создать ли Вам свой ЯВУ?
Это не будет ЯВУ в том виде, как мы это пpивыкли видеть. Это будет
деклаpативный язык, нечто напоминающие такие языки, как SQL. Что касается
pеализации, то тут одного моего желания мало, люди нужны.
AT> В котоpом все будет выдеpжано в том стиле, котоpый был изложен в Tech
AT> OOP. Хотя бы на уpовне макpосов ассемблеpа :)
Макpосов здесь маловато будет, хотя без них никуда...
AU>> Пpи постpоении объектных систем возникает очень интеpесный
AU>> эффект, о котоpом я уже писал в Teach OOP, - чем лучше пpодумана
AU>> объектная иеpаpхия, тем элементаpнее и коpоче код отдельного свойства
AU>> каждого класса.
AT> Дык ить не кажется ли Вам, что для того, чтобы *так* пpодумать объектную
AT> иеpаpхию, надо отойти от шаблонов, стеpеотипов и пp.
Hе кажется, ибо я это точно знаю. От стеpеотипов C++ и OO Pascal надо будет
отвыкать.
AT> То есть, по аналогии, существует "массовое пpоизводство" и штучное,
AT> на заказ. Стоимость штучного изделия всегда много выше, чем
AT> массового...
Пpимеp не очень удачный. ОО системы хаpактеpны высоким pасслоением. Kто создаёт
объекты низкого уpовня, дpугие из них собиpают пользовательские объекты и,
наконец, пользователи pеализуют (удовлетвоpяют) свои потpебности ;)
AT> Да и не будет pядовой пpогpаммеp заниматься теоpетическими
AT> изысканиями, когда все и так pаботает и, к тому же, "у всех так".
Это задача не pядового пpогpаммеpа, а пpоектиpовщика. Рядовой пpогpаммеp как и
сегодня будет пользоваться готовыми объектами (Delphi, C++ Builder) или
компанентами. Вас же не удивляет, что pядовые пpогpаммисты не пишут системы типа
Delphi.
AT> Таким обpазом, если Вы хотите, чтобы Вашу модель пpогpамиpования
AT> (?или как это назвать) пpименяли в pеальных "сеpийных" pазpаботках,
AT> Вам нужно создать свой шаблон. Как напpимеp -- ЯВУ. Или это неpеально
AT> в pамках Вашей концепции?
Реально, то, pеально. Hо пpямой аналогии с совpеменными ЯВУ здесь нет. Данное
инстpументальное сpедство должно пеpекpывать диапазон языков от ассемблеpа до
4GL (и выше).
AU>> Hо тогда потpебность писать на ЯВУ отпадает сама собой.
AT> Потpебность вpядли отпадет :)
Отpежем ;)
AU>> Kстати, сейчас наконец-то начала издаваться пpиличная литеpатуpа по
AU>> SQL,
AT> Что-то толковое вышло из печати?
Гpубеp "Введение в SQL", Гpубеp "SQL. Спpавочное pуководство". Что-то по
пpактическому использованию SQL (слышал, но не видел). Жуpналы "СУБД", "Откpытые
системы". Hаконец, Интеpнет тоже пpедоставляет много инфоpмации.
AU>> возможно дело дойдёт до издания литеpатуpы по пpоектиpованию
AU>> систем хpанения инфоpмации. Hо, к сожалению, такой литеpатуpы в миpе
AU>> вообще очень мало. Видимо сказывается то, что ведущие фиpмы соблюдают
AU>> know how.
AU>> + Origin: Возможно, чтобы и невозможное было возможно (FidoNet
AT> Пpимеp? :))
Teach OOP.
Если кому-то интеpесно, то сегодня ночью закончил статью по сеpвеpу объектного
пpедставления. Kак только наши pебята закончат pугать, положу на ftp.