哪些 RDBMS 可以最大限度地减少服务器往返次数？哪个 RDBMS（在这个领域）比 MS SQL 更好？
重要提示：我收到了很多答案，谢谢大家。但所有的答案都是评论多于答案。我的问题与每个 RDBMS 的往返次数有关。一位有经验的人告诉我，MySQL 的往返次数比 Firebird 少。我希望答案保持在同一区域。我同意这不是首先要考虑的事情，还有很多其他事情（应用程序设计、网络设置、协议设置...），无论如何我想收到我的问题的答案，而不是评论。顺便说一下，我发现这些评论都非常有用。谢谢。
当延迟很高时（“ping 服务器需要时间”），服务器往返会产生影响。
现在我不想关注在编程中创建的往返，而是在数据库引擎+协议+数据访问层“幕后”发生的往返。
我听说FireBird 比 MySQL 具有更多的往返次数。但这是我所知道的唯一信息。
我目前支持 MS SQL，但我想更改 RDBMS，因此为了做出明智的选择，我想将这一点也包含到“我的 RDBMS 比较功能矩阵”中，以了解哪个是最好的 RDBMS 选择作为替代方案微软SQL。
所以上面的粗体句子会让我更喜欢MySQL而不是Firebird（对于往返概念，不是一般情况），但是任何人都可以添加信息吗？
MS SQL 它位于哪里？ 是否有人能够对主 RDBMS 的往返性能进行“排名”，或者至少： MS SQL、MySql、Postegresql、Firebird（我对 Oracle 不感兴趣，因为它不是免费的，如果我必须更改，我会更改为免费的 RDBMS）。
无论如何，MySql（正如 stackoverflow 上多次提到的那样）的未来并不明朗，也不是 100% 免费的许可证。所以我的最终选择可能会是 PostgreSQL 或 Firebird。
其他信息：
不知何故，您可以通过制作一个简单的列表来回答我的问题，例如：
MSSQL:3;
MySQL：1；
火鸟：2；
Postgresql：2
（其中 1 好，2 一般，3 差）。当然，如果您可以发布一些比较每个 RDBMS 的往返次数的链接，那就太好了
更新：
我使用 Delphi，并且计划使用 DevArt DAC (UNIDAC)，因此某种程度上“相同”的数据访问使用组件，因此如果存在显着的往返差异，则这是由于使用的 RDBMS 不同造成的。
进一步更新：
我有一个 2 层应用程序（插入中间层不是一个选项），因此通过选择“往返端”优化的 RDBMS，我有机会进一步提高应用程序的性能该应用程序。这种“优化”就像“购买更快的互联网连接”或“在服务器上放置更多内存”或“升级服务器CPU”。无论如何，这些“优化”也很重要。
IMPORTANT NOTE: I recieved many answers and I thank you all. But all the answers are more comments than answers. My question is related on the number of roundtrips per RDBMS. An experienced person told me that MySQL has less roundtrips than Firebird. I would like that the answer stays in the same area. I agree that this is not the first thing to consider, there are many others (application design, network settings, protocol settings...), anyway I 'd like to recieve an answer to my question, not a comment. By the way I found the comments all very useful. Thanks.
When the latency is high ("when pinging the server takes time") the server roundtrips make the difference.
Now I don't want to focus on the roundtrips created in programming, but the roundtrips that occur "under the hood" in the DB engine+Protocol+DataAccessLayer.
I have been told that FireBird has more roundtrips than MySQL. But this is the only information I know.
I am currently supporting MS SQL but I'd like to change RDBMS, so to make a wise choice I would like to include also this point into "my RDBMS comparison feature matrix" to understand which is the best RDBMS to choose as an alternative to MS SQL.
So the bold sentence above would make me prefer MySQL to Firebird (for the roundtrips concept, not in general), but can anyone add informations?
And MS SQL where is it located? Is someone able to "rank" the roundtrip performance of the main RDBMS, or at least:
MS SQL, MySql, Postegresql, Firebird (I am not interested in Oracle since it is not free, and if I have to change I would change to a free RDBMS).
Anyway MySql (as mentioned several times on stackoverflow) has a not clear future and a not 100% free license. So my final choice will probably dall on PostgreSQL or Firebird.
Additional info:
somehow you can answer my question by making a simple list like:
MSSQL:3;
MySQL:1;
Firebird:2;
Postgresql:2
(where 1 is good, 2 average, 3 bad). Of course if you can post some links where the roundtrips per RDBMSs are compared it would be great
Update:
I use Delphi and I plan to use DevArt DAC (UNIDAC), so somehow the "same" Data Access component is used, so if there are significant roundtrip differences they are due to the different RDBMS used.
Further update:
I have a 2 tier application (inserting a middle tier is not an option), so by choosing a RDBMS that is optimized "roundtrip-side" I have a chance to further improve the performance of the application. This kind of "optimization" is like "buy a faster internet connection" or "put more memory on the server" or "upgrade the server CPUs". Anyway also those "optimizations" are important.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
为什么你专注于往返？通常它们不会影响您的性能，除非您的网络非常慢且不可靠。例如，任何数据库的 ODBC 和 OLEDB 驱动程序之间的差异几乎是一个数量级，有利于 OLEDB。
如果您使用 ODBC 而不是 OLEDB/ADO.NET 驱动程序访问 MySQL 或 Firebird，则会产生比您可能节省的往返次数大几个数量级的开销。
Why are you concentrating on roundtrips? Normally they shouldn't affect your performance unless you had a very slow and unreliable network. For example, the difference between ODBC and OLEDB drivers for any database is nearly an order of magnitude in favor of OLEDB.
If you go to either MySQL or Firebird using ODBC instead of OLEDB/ADO.NET drivers you incur an overhead several orders of magnituted greater than the roundtrips you might save.
应用程序的编码方式以及访问和传输数据的方式和时间在慢速连接或高延迟情况下比数据库网络协议本身具有更大的影响。一些数据库协议可以调整为在不常见的情况下更好地工作，即增加或减少数据包大小。
您还可能会遇到 TCP/IP 层本身速度变慢的情况，这也可能需要 TCP/IP 调整。
How your application is coded and how and when data are accessed and transferred have a much greater impact in slow connection or high latency situations than the db network protocol itself. Some database protocols may be tuned to better work in uncommon scenarios, i.e. increasing or decreasing the data packet size.
You may also encounter slow down at the TCP/IP layer itself, which could require TCP/IP tuning as well.
在 v2.1 之前，Firebird 产生的流量肯定比 MS SQL Server 更多。我有一个朋友在巴西开发了一个 MSSQL C/S 应用程序，该应用程序的数据库托管在数据中心。客户端应用程序从许多商店运行，使用最终用户宽带连接（大部分为 1Mbps）通过 VPN/Internet 直接连接到服务器，长达 5 年以上，没有出现任何问题。所涉及的距离从数据中心数百公里到数千公里不等。
在 v2.1 之后，我无法确定这是否仍然正确，因为自那以后我没有进行公平的比较，并且 Firebird 的远程协议已更改以优化慢速连接上的网络流量。有关 FirebirdSQL 站点的更多信息。
不能说 PostGres 或 MySQL，因为我没有使用任何。
Until v2.1, Firebird certainly creates more traffic than MS SQL Server. I have a friend which developed a MSSQL C/S application here in Brazil where the db is hosted in a datacenter. The client apps runs from many stores directly connecting on server over VPN/Internet using end-user broadband connections (1Mbps, mostly) for 5+ years and no trouble with it. The distances involved range from few hundred to thousands of kilometers from datacenter.
After v2.1, I can't figure out if this remains true, because I haven't made a fair comparison since and Firebird's remote protocol had been changed to optimize network traffic on slow connections. More on FirebirdSQL site.
Can't say on PostGres ou MySQL, since I didn't used any.
我无法提供往返详细信息，但不久前，当我由于预算原因试图寻找 MS SQL 的替代品时，我遇到了非常相似的情况。我和其他 4 个人花了一些时间比较 MySQL、Postgres 和 FireBird。
在使用 MySQL 很长时间后，我们很快就在大多数大型项目中排除了它。这个决定落在了 Postgres 和 FireBird 之间。刚刚开始的一件事是与 Postgres 相比，FireBird 缺乏流行的支持/文档。我们的基准测试总是Postgres 处于领先地位或与FireBird 持平，从不低于。从功能上来说； Postgres 再次满足了我们的需求，而 FiredBird 让我们需要提出创造性的解决方案。
以下是功能比较图表。我承认它现在有点过时了，但仍然非常有帮助：
这里还有一个很长的论坛主题讨论差异
祝你好运！
I can't give round trip details but i was in a very similar situation a while back when i was trying to find alternatives to MS SQL due to budgeting. myself and 4 others spent some time comparing MySQL, Postgres, and FireBird.
Having worked with MySQL for a long time we quickly ruled it out for most of our larger projects. The decision fell between Postgres and FireBird. One thing just starting off was the lack of popular support/documentation with FireBird in contrast to Postgres. Our bench tests always either had Postgres on top or on level with FireBird, never under. In terms of features; Postgres again answered our needs while FiredBird had us needing to come up with creative solutions.
Below is a feature comparison chart. i'll admit it is now a bit dated but still very helpful:
Here is also a long forum thread discussing the difference
Good luck!
有时“往返”也在协议或数据访问层中，而不是在“数据库引擎”中
Sometimes the "roundtrips" are also in the protocol or data access layer, not the "DB engine"
我不会从往返方面对客户端-服务器 DBMS 进行排名。有很多选项可以使一种 DBMS 成为最好的（要求 SQL Server 使用默认游标），或使另一种 DBMS 变得更差（使用嵌套数据集创建 Oracle 游标）。
您正在寻找的可能是通用方法，面向流量最小化和客户端与服务器的独立工作。那是中间层数据访问库。
因此，如果您的应用程序对流量优化如此敏感，那么请寻找这样的库，例如 DataAbstract、kbmMW 或 ThinDAC。
I will not rank the client-server DBMS's from the roundtrips side. There are a lot of options to make one DBMS the best (ask SQL Server to use the default cursor), and other the worse (create an Oracle cursor with nested datasets).
What you are looking for is, probably, the general approach, oriented on the trafic minimization and the independent work of a client from a server. That are the middle-tier data access libraries.
So, if your application is so sensitive to the trafic optimization, then look for such libraries like the DataAbstract, kbmMW or ThinDAC.