我正在设计一个可能小于100 MB的基础,拥有自己的服务器,并将通过Intranet Java EE Web应用程序进行读取和修改.我已经找到了很多关于优化大型基础的参考资料,我知道这是一个更为关键的问题,但我有很多时间,读取/插入速度是项目优先级,我很确定我不知何故,可以利用如此小的总db大小.当然,除非MySQL已经自然地针对那种小型基准进行了优化.
当然,它确实适合内存,但我需要它的数据实际上在磁盘上持久存在,或者至少不久就会保存到磁盘上; 我已经想到了一些疯狂的替代方案,比如在第一次需要时(在用户连接时,很可能？)以某种方式顺序将整个基本加载到内存中,并稍后将其提交到磁盘.
但是我觉得最好在这里问一下,看看有人之前是否遇到过这种情况,并且从小基数中获利是个不错的主意.
我在数据库访问方面的思考更多,而不是结构,但如果某人有小型基础的结构设计技巧并且认为他们使访问优化问题完全无关紧要,那么这也可能是一个恰当的反应.
提前致谢.
编辑:应用程序是有点关键的,在我完成之后,它将由主要用于MySQL的人开发,因此不同的DBMS不是一个选项,除非它们与MySQL类似.
我想到的具体情况如下:AjaxFormComponentUpdatingBehavior("onchange")被添加到表单中的TextField.该行为验证某些条件的文本(模型对象或表单组件模型,无关紧要),根据它可以显示消息(或隐藏它,如果已经显示).
问题是,还有一些验证器添加到TextField.其中一个可能的(也可能是)场景包括用户输入,首先是一个导致消息由AJAX请求显示的值.然后,如果他/她键入了未通过验证的值,则消息应该消失,但事实并非消失.
显然,根本没有调用AJAX行为的onUpdate()方法,或者我试图插入对未经验证的条目的检查失败(我试图测试空值和空字符串,否则可用;我不知道Wicket的验证器在数据无效时对模型做了什么.
我想知道是否有人真正了解验证器(或实际上是AJAX)对问题的位置有任何想法.
我可以发布编辑和发布代码,如果有人告诉我这不是绑定验证器和AJAX的一般问题,但很可能是编程错误.我仍然相信前者,因此我将避免发布代码部分,以便继续讨论API /理论框架.
谢谢.