2 Vdimas\r
\r
Читал Ваше сообщение, касающееся возможной реализации неделю :) Ну что сказать?\r
\r
Для начала хочу припомнить топик "Система с изменяющимися алгоритмами рассчета". Наскоолько я понял, ее автор
ASCRUS , посчитал возможности, предоставляемые совпременными реляционными СУБД (то есть того, что я в предыдущих выступлениях называю "табличными машинами") вполне достаточными для реализации, причем не только по языковым возможностям, но и по производительности (и вообще если говорить про то, что реализовал ASCRUS (насколько я это понял), то ИМХО - еще немного, и мы получим то, о чем я говорю....2 ASCRUS - наверное, это намёк:) )\r
\r
Я по поводу разговора по ОЗУ и ВЗУ, и про адресацию в ОЗУ и в ВЗУ. В том то все и дело, что реляционные СУБД ушли от этого деления. В них существуют просто данные. Как и где они храняться в данный момент в железной машине, как ОЗУ отображать в ВЗУ - все эти вопросы рещаются внутри РСУБД внутри нашей табличной машины. Сама же она предоставляет данные в виде того, что я называю "табличной" памятью.\r
\r
Давайте дальше. Можно выделить два типа - адресный и ассоциативный. Первый означает, что для доступа к данным мы используем адрес переменной, где эти данные храняться. Второй означает, что для доступа к данным мы должны найти их, среди других данных. Первый конечно быстрее, но за счет чего? за счет того, что мы используем возможности, предоставляемые системой хранения, то есть наши данные к этой системе хранения привязаны Второй способ (реализуемый реляционными системами), конечно медленнее, но зато он опирается только на данные, то есть от системы хранения не зависит. Если же разбирать этот вопрос более детально, то выясниться, что быстродействие - это единственный козырь адресного доступа (мы нашли быстро или не очень быстро, но в любом случае нашли). В конце концов, если бы дело упиралось только в быстродествие, то реляционные СУБД никогда не победили бы иерархические и сетевые системы, поскольку последние всегда будут быстрее.\r
\r
Зачем вообще говорить про адреса в ОЗУ и ВЗУ и про их привязку, если "табличная" машина позволяет вызвать некую процедуру просто по имени, то есть ассоциаивно? И OID у меня явлется "системным" только на уровне представления данных, а на уровне хранения он, наравне с другими данными, храниться в таблице и, следовательно, доступ к объекту реализуется так же ассоциативно (то ест OID вообще никаким боком к адресам на уровне железа не относиться).\r
\r
О чем я гвоврю? Например, следующий код,
ОПИСЫВАЮЩИЙ данные на уровне представления данных\r
\r
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
CREATE TABLETYPE sometable//здесь мы НЕ создаем табличную переменную! Это просто\r
объявление и описание табличного типа\r
{\r
...//перечисление полей - атрибутов отношения, например\r
i int;\r
}\r
\r
CREATE CLASS base_c\r
{\r
t sometable; // "t sometable" - это, фактически, сигнатура табличного атрибута.\r
// в данном случае (т.к. не определно иное) предполагается, что этот атрибут будет храниться\r
\r
}
\r
\r
на уровне хранения фактически будет преобразован в набор хранимых ПРОЦЕДУР.\r
\r
CREATE TABLETYPE будет преобразован в процедуру создающую таблицу system_sometable уровня хранения, причем структура этой таблицы будет соответсвовать описанию полей sometable, плюс два системных поля 1)для OID и 2)для имени атрибута объекта (эта таблица будет использоваться для ВСЕХ объектных атрибутов типа sometable - это может быть t, это может быть другой атрибут этого класса или атрибут другого класса). Эта процедура будет вызвана либо сразу, либо тогда когда появиться первый хранимый объектный атрибут типа sometable. \r
\r
CREATE CLASS base_c будет преобразовано в процедуру, добавляющее в таблицу атрибута t (то есть в таблицу system_sometable) новой записи, системные поля которой будут содержать 1) OID создаваемого объекта и 2) имя атрибута "t". К тому же на этом этапе в каталог будет занесена информация, что значение атрибута t класса base_c хранится в таблице system_sometable.\r
\r
Теперь можно создавать объект
получив такую команду, система 1) генерит новый OID и 2) вызывает процедуру созданную на предыдущем этапе. Соответсвенно в таблице system_sometable появиться новая запись с соответсвующими системными полями. Поскольку OID сохранен в ссылосной переменной o, то можно написать
что, исходя их того, что значения атрибута t храняться в system_sometable (это записано в каталоге классов), будет преобразовано в \r
1.
2.
3.
UPDATE system_sometable SET i = 1 WHERE ...\r
//отбор по следующим критериям \r
// 1 ) системное поле, хранящие OID равно значению o и \r
// 2 ) системное поле хранящие имя атрбута равно "t"
\r
Соответсвенно и вся процедура уровня представления (например метод класса), где мы работаем со ссылочными переменными, объектными атрибутами и т.п. вещами присущими ОО языкам, на уровне хранения может быть преобразована в хранимую процедуру реляционной СУБД.\r
\r
И еще раз повторю - я не озабочен производительностью. Есть несколько причин\r
1) я не озабочен ей как ..мммм...теоретик :) По мне, так "табличные" машины (реляционные СУБД) работают бесконечно бысто. Для меня более важно, что бы троица "входное воздействие, реализация, результат" были ОДНОЗНАЧНО определены\r
2) Реальность такова, что "табличная" машина уже работают с приемлемой скоростьтю (в качестве примера можно привести все тот же топик "Система с изменяющимися алгоритмами рассчета".\r
3)В конце концов, я думаю, что UPDATE, подобный последнему не такая уж и страшная штука. Такие UPDATE\'ы приходиться делать много раз на дню, но то их пишут вручную, а тут их сгенерила система. Я уже писал, что ИМХО для производительности гораздо важнее то, что стуктура таблиц на уровне хранения определяется в общем то нормализацией данных, и практически не отличается от структуры аналогичной "традиционной" РБД. \r
\r
И если мы так сделаем, что вопрос\r
>>6. НО... Это СУБД??? Или просто получили прикольную приложуху? \r
отпадает сам собой. По большому счету он отпадает именно потому, что мы сохраняем главное преимущество РСУБД - ассоциативный доступ к данным, доступ по значениям и по именам, определенным в описании данных. Нам не обязательно хранить ссылку на объект. Мы можем всегда найти его среди других объектов класса base_c по его атрибуту t.i который равен единице. И никакие "объекты-хелперы для каждого прикладного класса, через которые можно перебрать все объекты класса" для этого в принципе не нужны. Система просто преобразует запрос, обращенный к классу base_c и к его атрибуту t в запрос к таблице system_sometable (так записано в каталоге классов). Там она может по i = 1 найти любые данные, и самое главное, она может найти OID(!) объекта, который может быть в дальнейшем использован. Другим словами, мы можем
вернуть ссылку на объект по данным объекта . Реализация такого процесса в ОЗУ или ВЗУ (то есть в адресной памяти) дело ИМХО по крайне мере нетривиальное :).\r
\r
Далее. Если мы опишем конструктор\r
\r
1.
2.
3.
4.
CREATE CLASS base_c\r
{\r
t sometable; \r
base_c(ci int){ t.i = ci; } // это конструктор, значица\r
}
\r
то операцию\r
\r
мы сможем использовать не только в теле некоего метода, но и как команду НЕПРОЦЕДУРНОГО доступа к нашей системе (вот вам и расширение SQL). В принципе мы можем написать и просто\r
\r
однако в этом случае объект будет потерян, но не потому, что на него нет ссылки, а потому, что он не инициализирован какими-либо данными (то есть вновь всплывает различие между адресным и ассоциативным доступом). \r
\r
Так что я вижу реализацию иключительно средствами, предоставляемыми реляционными СУБД или, как я писал выше, "табличными" машиной. И (еще раз повторю) возможность такой реализации ИМХО очень убедительно показана в топике "Система с изменяющимися алгоритмами рассчета"....и все же это намек :)
