2 个数据库，还是 1 个？
我有一个所有国家和城市的数据库，我想使用ajax用它在表格中的国家城市字段中给出建议，我的数据库中有很多与网站内部运作相关的表格。如果我把它放在不同的数据库中（只是这个世界地图数据库）可以吗？我宁愿把它放在不同的数据库中，这样它更有组织性，而且我不会真正在连接到主数据库的同一页面上连接到它。基本上是一个小的 php 页面，会建议带有 json 的字符串。我想知道单独的数据库是否意味着共享数据库池并降低性能！？
我应该补充一点，这些新表是 geobytes.com 上的 sql 脚本，我不知道它们有多好，也不知道我是否会在以后使用它们！我希望通过最新的 ip 表列表找到更好的东西！像 ip2location
I have a database of all countries and cities, I would like to use ajax to use it to give suggesstions in the country cities fields in forms, I have a lot of tables in my db related to the inner workings of the site. Is it ok if I put this in a different database (just this world map database)? I rather put it in a different db so it's more organized and I wouldnt really be connecting to it on the same pages that I connect to the main database. basically a small php page that will suggest strings with json. I was wondering if a seperate db means sharing the db pooll and decrease of performance!??
I should add that these new tables are and sql script on geobytes.com and I don't know how good they are or if I am gonna use them down the path! I hope to find something better with a uptodate list of ip tables! like ip2location
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这并没有什么特别错的。我不知道它是否有必要 - 如果它只是一两张桌子，我不明白为什么它对性能或安全性如此重要，无论哪种方式。如果您担心脚本访问这些附加表，您可以为 json 脚本使用不同的数据库用户名，并将其设置为只读，这样如果它确实以某种方式被利用，它就无法更改您的其他表。
老实说，我认为你最好的选择是暂时将其保留在一个数据库中，但是编写足够灵活的脚本，以便在需要时可以将其指向一个单独的数据库。
There's nothing particularly wrong with that. I dont know if its necessary - if its just a table or two I cant see why it'd matter much performance or security wise, either way. If you are concerned about the script accessing those additional tables, you can use a different database user name for your json script and set that to read only so that if it does get exploited somehow, it cant alter your other tables.
Honestly I think your best bet is to keep it in one db for now, but write your script flexible enough that you can point it at a separate database should the need ever arise.
避免过早优化。如果您试图将事物分开（出于架构原因），那么也没有问题。如果您正在尝试提高性能，那么您怎么知道这会提高性能呢？您将需要额外的数据文件的开销，并且数据库服务器上可能会需要更多的开销来管理多个数据库。
最好的情况下，这可能只是一次性能洗礼。
Avoid premature optimization. IF you're trying to keep things separate (for architectural reasons), then that's fine. If you're trying to increase performance, then how do you know that this will even increase performance at all? You'll have the overhead of additional data files, possibly with more overhead on your database server to manage multiple databases.
At best it's probably a performance wash.
我不太明白你为什么要这样做。它使事情变得复杂：
我会将这些表暂时保留在原处。如果/当它们导致性能问题时将它们拉出来。
I don't quite understand why you'd want to do this. It complicates things in terms of:
I would leave these tables where they are for the moment. Pull them out if/when they cause you a performance problem.
如果您需要横向扩展，您的应用程序已经将它们分开，所以会更容易。如果出现性能问题，您可以将第二个数据库放在第二台计算机上。
如果您有多个核心数据库服务器，那么对于大多数应用程序来说，将它们放在一台计算机上应该不成问题。
If you ever need to scale out, your app would already have them split, so it would be easier. You could put the second database on a second machine if it becomes a performance issue.
If you have a many core database server, having them on a single machine shouldn't be a problem for most apps.
听起来这个地理参考数据是您自己的，而您的网站有很多其他“内部运作”。
您的网站是 CMS 或来自第 3 方的类似网站 - Drupal/Joomla/等？
如果是这样，请将您自己的数据保留在其中。如果您计划将此地理数据公开给 Web 服务，那么它是独立的。
如果该站点是您自己的站点，请考虑该数据库中的其他表与您的地理参考表之间的标准化程度。
Sounds like this geographical reference data is your own, whereas your website has a lot of other 'inner workings'.
Is your website a CMS or similar from a 3rd party - Drupal/Joomla/etc?
If so, keep your own data out of there. If you're planning on exposing this geographical data to a web service, it stands by itself.
If this site is your own, consider how much normalization is between the other tables in that database to your geographic reference tables.