在为多个客户端设计的以数据库为中心的应用程序中,我一直认为为所有客户端使用单个数据库"更好" - 将记录与适当的索引和密钥相关联.在收听Stack Overflow播客时,我听到Joel提到FogBugz每个客户端使用一个数据库(所以如果有1000个客户端,则会有1000个数据库).使用这种架构有什么好处？
据我所知,对于某些项目,客户需要直接访问所有数据 - 在这样的应用程序中,很明显每个客户端都需要自己的数据库.但是,对于客户端不需要直接访问数据库的项目,每个客户端使用一个数据库有什么好处吗？似乎在灵活性方面,使用具有表的单个副本的单个数据库要简单得多.添加新功能更容易,创建报告更容易,而且管理起来更容易.
我对"所有客户的一个数据库"方法非常有信心,直到我听到Joel(一位经验丰富的开发人员)提到他的软件采用了不同的方法 - 我对他的决定感到有些困惑......
我听说人们引用数据库会因为大量记录而变慢,但任何具有一些优点的关系数据库都不会出现这个问题 - 特别是如果使用了正确的索引和键.
任何输入都非常感谢!
虽然跨站点脚本通常被认为是负面的,但我遇到了一些必要的情况.
我最近在一个非常有限的内容管理系统的范围内工作.我需要在页面中包含数据库代码,但托管服务器没有任何可用的可用内容.我在自己的服务器上设置了几个简单的脚本,最初认为我可以使用AJAX将脚本的内容直接导入到CMS的模板中(从而保留动态图像,菜单项,CSS等).我错了.
由于XMLHttpRequest对象的限制,无法从其他域获取内容.所以我认为iFrame - 即使我不是框架的粉丝,我认为我可以创建一个与内容的宽度和高度相匹配的框架,这样它就会显得原生.再次,我被跨站脚本"保护"阻止了.虽然我确实可以将远程文件加载到iFrame中,但我无法在主机页面或加载页面内部执行JavaScript来修改其大小.
在这种特殊情况下,我无法将子域指向我的服务器. 我也无法在CMS服务器上创建可以从我的服务器代理内容的脚本,所以我最后的想法是使用远程JavaScript.
远程JavaScript工作.当用户禁用JavaScript时,它会中断,这是一个缺点; 但它的确有效.我使用远程JavaScript时遇到的"问题"是我必须使用JS函数document.write()输出任何内容.任何不是JS的输出都会导致脚本错误.除了document.write()用于每一行之外,还必须确保内容被转义 - 否则最终会出现更多脚本错误.
我的解决方案如下:
我的脚本收到一个GET参数("页面"),然后查找文件({$page}.php),并将内容读入变量.但是,我必须使用笨拙的缓冲技术才能实际执行包含的脚本(对于像数据库交互这样的事情),然后删除所有换行符(\n)的最终内容,然后转义所有必需的字符.最终结果是我的原始脚本(输出JavaScript)访问我服务器上看似"标准"的脚本,并将其标准输出转换为JavaScript以便在CMS模板中显示.
虽然这个解决方案有效,但似乎可能有更好的方法来完成同样的事情.使跨站点脚本工作专门用于包含来自完全不同的域的内容的最佳方法是什么？