作者在 2007-01-03 02:29:00 发布以下内容
当今占主导地位的数据库系统是关系型数据库系统，关系型数据库系统给我的感觉是不直观，学习难度大，并且要求使用者完全掌握sql 语言，而sql 语言在很大程度上限制了思想者的思维方式，这一点是必须改变的。当一个人使用一样工具时感到十分别扭的时候，那么他必然会去寻找一个更合适的工具。 我认为语言必须是自由的，也就是说，使用语言者可以用各种方式来表达同样一件事情而不必受到语言的限制和束缚。所以sql 的时代必须结束。
所谓数据库当然就是一个用于存放数据的地方，此外数据库系统必须具有对数据的管理能力。
让我们把目光拉回到现实生活中，在我们的现实生活中我们每天接触的地的确确是对象，是一件件真实的物件。 在我们的仓库中存放的也的的确确是实实在在的物品，是object. 在我们的仓库中并没有什么table. 一个十分重要的概念到这里必须提出来了，那就是容器(container) 一个仓库其实就是一个容器，那么数据库就是一个存放数据的容器。
我认为，如果我们能够模拟现实生活中的仓库，那么我们就实现了对象化数据库，而所谓系统就是说在存放对象的基础上进一步实现管理。为了便于理解，我进一步将对象化数据库称为对象库(object storehouse), 以及将对象化数据库系统称为对象库管理系统(object storehouse management system)。
那么对象库管理系统(OSMS) 到底应该是怎么样的呢？这是作为开发人员必须思考的问题，我对这个问题进行了长期的思考，我试图以我独立的方式来创立一个新的技术，也就是说我试图不进入他人已有的模式，(事务是多维的，往往当你受到某种固有模式限制住的时候，你是很难摆脱它的，这样也就使得你无法看到事物的多维性。所以有时候无知也不是坏事.)
我给出我的思考结果:
1. 对象库管理系统(OSMS) 必须提供建立系统模型的能力, 也就是说当你得到这个OSMS 的时候你也得到了一个建模软件, 所谓建模软件可以是直观的通过操作建模单元(矩形框)图形化的实现系统建模. 建模软件同时也提供你以书写代码的方式来实现系统建模.
2. OSMS 应具备对对象的管理能力, 管理能力体现在: 对象的加入, 对象的流出, 对象的状态变更. 当发生以上事件时, 对象库就必须得到更新, 事实上对象库的更新是始终在发生的, 并且是自动的, 伴随性的发生的, 因为它们都是对象.
3. OSMS 应该具备将对象库信息向外界展示的能力, 使得程序员(用户)能够以自己的方式来处理对象. 这一点是很重要的, 这将提供给程序员一个完全的自由, 程序员不再受到 sql 的困扰. 程序员可以看到对象库的整体信息, 即系统模型的整体构架, 程序员也可以进入对象库的局部, 从而操作局部的对象, 程序员可以完全自由的在对象库中穿行, 以自己的方式来操作对象, 这就好比你可以自由到一个仓库中去, 去看看那里放了什么, 你可以用你自己的方式来统计对象的个数, 比较, 整理等等.
4. OSMS 同样也应该具备自己的分析能力, 自己对对象库的操作能力, 也就是说如果程序员愿意的话, 他可以借助OSMS 所提供的帮助而实现对对象的操作. 为此, 就必须提供一系列api, 请注意, 我不是提供询问语言而是提供 api, 程序员可以使用这些api 来高效的实现对对象库的操作, 这里也包含了对对象信息的询问. 为了便于理解, 我给出一个很简单的例子:
通常这样一个sql 语言 select * from sometable. 你会得到该表的所有列项的信息. 那么用我的语言怎么来写呢? 写法可以是这样的:
System.display(someContainer); 而这个display() 函数便是一个系统函数. 你甚至可以使用这个display 函数显示整个对象库的模型. 比如某个图书馆用该系统建立了对象库取名为myLibrary, 那么如果你使用 System.display(myLibrary); 你别可以得到完整的对象库模型的文字表达, 如果你想看到整个模型的图形表达呢? 那么也很简单, 一, 你可以通过系统自带的界面化软件来实现图形界面操作, 就像打游戏一样, 操作对象库是不是不再枯草? 你也在console 界面输入命令 System.graphDisplay(myLibrary); 当你按下回车的时候, 图形化界面就跳出来了. 如果你不清楚你怎么操作, 该怎么做呢? 很简单, 输入help, 便会得到一个帮助菜单, 如果你进一步想知道有哪些命令, 那么你输入help command, 按下回车便可看到所有的系统命令了.
说到这里, 必须总结一下了, OSMS 意味着提供两样东西给用户, 一个就是图形化界面软件, 一个就是console 操作界面, 使用者完全可以自由的自我选择, 有一点是清楚的, 我们不再提供sql 支持.
5. OSMS 具有对对象模型作出更改的能力, 比如模型的扩展, 局部更改, 或者整体的删除.
以上便是我目前对对象库操作系统(OSMS)的思考以及我所认为的一些方案. 欢迎大家的评论.
所谓数据库当然就是一个用于存放数据的地方，此外数据库系统必须具有对数据的管理能力。
让我们把目光拉回到现实生活中，在我们的现实生活中我们每天接触的地的确确是对象，是一件件真实的物件。 在我们的仓库中存放的也的的确确是实实在在的物品，是object. 在我们的仓库中并没有什么table. 一个十分重要的概念到这里必须提出来了，那就是容器(container) 一个仓库其实就是一个容器，那么数据库就是一个存放数据的容器。
我认为，如果我们能够模拟现实生活中的仓库，那么我们就实现了对象化数据库，而所谓系统就是说在存放对象的基础上进一步实现管理。为了便于理解，我进一步将对象化数据库称为对象库(object storehouse), 以及将对象化数据库系统称为对象库管理系统(object storehouse management system)。
那么对象库管理系统(OSMS) 到底应该是怎么样的呢？这是作为开发人员必须思考的问题，我对这个问题进行了长期的思考，我试图以我独立的方式来创立一个新的技术，也就是说我试图不进入他人已有的模式，(事务是多维的，往往当你受到某种固有模式限制住的时候，你是很难摆脱它的，这样也就使得你无法看到事物的多维性。所以有时候无知也不是坏事.)
我给出我的思考结果:
1. 对象库管理系统(OSMS) 必须提供建立系统模型的能力, 也就是说当你得到这个OSMS 的时候你也得到了一个建模软件, 所谓建模软件可以是直观的通过操作建模单元(矩形框)图形化的实现系统建模. 建模软件同时也提供你以书写代码的方式来实现系统建模.
2. OSMS 应具备对对象的管理能力, 管理能力体现在: 对象的加入, 对象的流出, 对象的状态变更. 当发生以上事件时, 对象库就必须得到更新, 事实上对象库的更新是始终在发生的, 并且是自动的, 伴随性的发生的, 因为它们都是对象.
3. OSMS 应该具备将对象库信息向外界展示的能力, 使得程序员(用户)能够以自己的方式来处理对象. 这一点是很重要的, 这将提供给程序员一个完全的自由, 程序员不再受到 sql 的困扰. 程序员可以看到对象库的整体信息, 即系统模型的整体构架, 程序员也可以进入对象库的局部, 从而操作局部的对象, 程序员可以完全自由的在对象库中穿行, 以自己的方式来操作对象, 这就好比你可以自由到一个仓库中去, 去看看那里放了什么, 你可以用你自己的方式来统计对象的个数, 比较, 整理等等.
4. OSMS 同样也应该具备自己的分析能力, 自己对对象库的操作能力, 也就是说如果程序员愿意的话, 他可以借助OSMS 所提供的帮助而实现对对象的操作. 为此, 就必须提供一系列api, 请注意, 我不是提供询问语言而是提供 api, 程序员可以使用这些api 来高效的实现对对象库的操作, 这里也包含了对对象信息的询问. 为了便于理解, 我给出一个很简单的例子:
通常这样一个sql 语言 select * from sometable. 你会得到该表的所有列项的信息. 那么用我的语言怎么来写呢? 写法可以是这样的:
System.display(someContainer); 而这个display() 函数便是一个系统函数. 你甚至可以使用这个display 函数显示整个对象库的模型. 比如某个图书馆用该系统建立了对象库取名为myLibrary, 那么如果你使用 System.display(myLibrary); 你别可以得到完整的对象库模型的文字表达, 如果你想看到整个模型的图形表达呢? 那么也很简单, 一, 你可以通过系统自带的界面化软件来实现图形界面操作, 就像打游戏一样, 操作对象库是不是不再枯草? 你也在console 界面输入命令 System.graphDisplay(myLibrary); 当你按下回车的时候, 图形化界面就跳出来了. 如果你不清楚你怎么操作, 该怎么做呢? 很简单, 输入help, 便会得到一个帮助菜单, 如果你进一步想知道有哪些命令, 那么你输入help command, 按下回车便可看到所有的系统命令了.
说到这里, 必须总结一下了, OSMS 意味着提供两样东西给用户, 一个就是图形化界面软件, 一个就是console 操作界面, 使用者完全可以自由的自我选择, 有一点是清楚的, 我们不再提供sql 支持.
5. OSMS 具有对对象模型作出更改的能力, 比如模型的扩展, 局部更改, 或者整体的删除.
以上便是我目前对对象库操作系统(OSMS)的思考以及我所认为的一些方案. 欢迎大家的评论.