blocks|key|3031008|text|您可以从Rails调用存储过程，但是您将失去ActiveRecord的大部分好处，因为标准生成的SQL将不起作用。您可以使用本机数据库连接并调用它，但这将是一个泄漏的抽象。您可能会考虑使用DataMapper。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3031009|摘自>>+Using+Stored+Procedures+in+Rails|offset|length|3031010|总之，这不是使用存储过程的"RAILS方式“。|3031011|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1953001/using-stored-procedures-in-rails^0|0|5|W|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

You can call stored procedures from Rails, but you are going to lose most of the benefits of ActiveRecord, as the standard generated SQL will not work. You can use the native database connection and call it, but it's going to be a leaky abstraction. You may want to consider DataMapper.

taken from >> <a href="https://stackoverflow.com/questions/1953001/using-stored-procedures-in-rails">Using Stored Procedures in Rails</a>

To sum up, its not the "RAILS WAY" to use stored procedures.

blocks|key|3031069|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3031070|不喜欢使用存储过程/sql函数是一种常见的做法吗？|blockquote|3031071|3031072|3031073|这是很常见的，大多数Rails应用程序只需要使用ActiveRecord。|3031074|Rails背后的一个主要理念是，今天将一个可用的产品推向市场比在6个月后将一个“快速”的产品推向市场更重要。几乎可以肯定的是，您的产品永远不会受到足够的欢迎，以至于性能成为一个问题。如果这确实成为一个问题，您可以稍后支持性能方面的事情，但当前的关注点是能够快速构建应用程序，并能够根据市场快速重构部分或全部应用程序。|3031075|3031076|使用存储过程的优缺点是什么？|3031077|3031078|3031079|它们编写起来更慢，更难更改，因此会提前承担您的开发成本。但是，它们的执行速度可能会更快。|3031080|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|W|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|X|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|K|3|L|4|C|6|Z|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|12|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|13|7|@]|8|@]|9|$]]]|R|$]]

<blockquote>
 Is it common practice that stored procedures/sql functions are not preferred to use?
</blockquote>

It is very common, most Rails apps will never need to use anything more than ActiveRecord.

One of the chief philosophies behind Rails is that it's more important to get a working product to market today than it is to get a "fast" product to market 6 months from now. Your product will almost certainly never be popular enough for performance to be a concern. If that does become a problem, you can shore up the performance side of things later, but the immediate concern is to be able to build an app quickly, and to be able to rapidly refactor some or all of it in response to your market.

<blockquote>
 What are pros and cons of using stored procedures?
</blockquote>

They're slower to write and more difficult to change, and therefore front-load your development costs. However, they can be faster to execute.

blocks|key|2818525|text|使用存储过程可能不是"rails方式“，但使用外键约束也不是”rails方式“，我们都知道这是一个多么糟糕的设计决策。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2818526|因此，我对“rails+way”持保留态度。如果存储过程对您有效，请使用它们。|2818527|这就是我要做的。由于了解到ORM通常不能真正“理解”存储过程，因此我避免直接使用它，而是创建一个实例化视图来封装存储过程，然后将其表示为一个常规表。正确设置后，这将为ORM提供一些它可以更好地理解的东西，同时仍然利用将数据库逻辑保留在它应该存在的层中的优势，数据库是一个在数据处理方面总是优于web框架的引擎。|2818528|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It might not be the &quot;rails way&quot; to use stored procedures but its also once not &quot;The rails way&quot; to use foreign key costraints, and we all know what a monumentally bad design decision that turned out to be.
So I would take &quot;the rails way&quot; with a grain of salt. If stored procedures work for you, use them.
Heres what I do. Understanding that ORMs often dont really 'understand' stored procedures without slightly more in depth magic, I avoid using it directly, but instead create a materialized view that encapsulates the stored procedure and then presents it as a regular table. Correctly set up, this gives the ORM something it can better understand whilst still leveraging the advantages of keeping database logic inside the layer its supposed to live in, the database, an engine that will always outperform the web framework at data crunching.

blocks|key|2818535|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2818536|不喜欢使用存储过程/sql函数是一种常见的做法吗？|blockquote|2818537|2818538|2818539|是真的。使用活动记录构建查询允许您在应用程序代码中管理所有这些查询。|2818540|2818541|使用存储过程的优缺点是什么？|2818542|2818543|2818544|的优点：你可以在你的应用程序代码中隐藏复杂的查询逻辑。|offset|length|style|BOLD|2818545|缺点：如果你想重写一个过程，你必须创建并执行一个迁移。|2818546|See+this+example+on+hiding+logic+in+a+database+view,+also+applicable+to+procedures.|2818547|优点示例：|2818548|您需要选择所有房间在start_time和end_time之间的酒店。每个酒店都有total_rooms+(整数属性)、hotel_times+(定义酒店营业时间的实体)和一些bookings+(定义预订酒店房间的用户的实体)。一些酒店很大，每天都提供预订。其他酒店规模较小，提供按小时预订的服务。您可以询问用户何时想要预订，可以是日期，也可以是有时间的日期。|CODE|2818549|这涉及到一些连接和子查询，并将创建一大段丑陋的活动记录代码。相反，您可以编写一个过程并像这样调用它：|2818550|Hotel.find_by_sql+['SELECT+*+FROM+hotels_available_between(?,+?)',+start_time,+end_time]|code-block|syntax|javascript|2818551|将其封装在一个作用域中，并获得更多的ruby-ish：|2818552|class+Hotel+<+ActiveRecord::Base
++scope+:available_between,+->+start_time,+end_time+do
++++find_by_sql+['SELECT+*+FROM+hotels_available_between(?,+?)',+start_time,+end_time]
++end
end

Hotel.available_between+start_time,+end_time|2818553|entityMap|0|LINK|mutability|MUTABLE|url|https://blog.codeship.com/speed-up-activerecord^0|0|0|0|0|0|0|0|0|0|0|4|0|0|3|0|0|2B|0|0|0|5|0|A|A|L|8|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|1K|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1L|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1M|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1N|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1O|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1P|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|1Q|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|1R|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|1S|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|1T|7|@$O|1U|P|1V|Q|R]]|8|@]|9|$]]|$1|S|3|T|4|5|6|1W|7|@$O|1X|P|1Y|Q|R]]|8|@]|9|$]]|$1|U|3|V|4|5|6|1Z|7|@]|8|@$O|20|P|21|1|22]]|9|$]]|$1|W|3|X|4|5|6|23|7|@$O|24|P|25|Q|R]]|8|@]|9|$]]|$1|Y|3|Z|4|5|6|26|7|@$O|27|P|28|Q|10]|$O|29|P|2A|Q|10]]|8|@]|9|$]]|$1|11|3|12|4|5|6|2B|7|@]|8|@]|9|$]]|$1|13|3|14|4|15|6|2C|7|@]|8|@]|9|$16|17]]|$1|18|3|19|4|5|6|2D|7|@]|8|@]|9|$]]|$1|1A|3|1B|4|15|6|2E|7|@]|8|@]|9|$16|17]]|$1|1C|3|-4|4|5|6|2F|7|@]|8|@]|9|$]]]|1D|$1E|$4|1F|1G|1H|9|$1I|1J]]]]

<blockquote>
 Is it common practice that stored procedures/sql functions are not preferred to use?
</blockquote>

True. Building queries with Active Record allow you to manage them all in your application code.

<blockquote>
 What are pros and cons of using stored procedures?
</blockquote>

Pros: you can hide complex query logic from your application code.

Cons: you have to create and execute a migration if you want to rewrite a procedure.

<a href="https://blog.codeship.com/speed-up-activerecord" rel="nofollow noreferrer">See this example on hiding logic in a database view, also applicable to procedures.</a>

Pros Example:

You need to select all hotels with rooms available between <code>start_time</code> and <code>end_time</code>. Every hotel has total_rooms (integer attribute), hotel_times (entity that define operating hours for a hotel) and some bookings (entity that define a user that booked a room in a hotel). Some hotels are big and offer daily bookings. Other hotels are small and offer hourly bookings. You ask the user when he wants to book, which can be either a date or a date-with-time.

This involves some joins and sub-queries and would create a big ugly piece of Active Record code. Instead, you can write a procedure and call it like this:

<pre><code>Hotel.find_by_sql ['SELECT * FROM hotels_available_between(?, ?)', start_time, end_time]
</code></pre>

Wrap it in a scope and get more ruby-ish:

<pre><code>class Hotel &lt; ActiveRecord::Base
 scope :available_between, -&gt; start_time, end_time do
 find_by_sql ['SELECT * FROM hotels_available_between(?, ?)', start_time, end_time]
 end
end

Hotel.available_between start_time, end_time
</code></pre>

I am a .net guy with 6 years of experience. Recently I started working on ROR project and realized that stored procedures/sql functions are not being used at all. On inquiring about it I got to know that it is common practice and in general nobody in team writes a sql queries at all, everything is done using ActiveRecord.

I googled about any possible reasons for this but didn't find much information. So I am just curios to know 

<ol>
<li>Is it common practice that stored procedures/sql functions are not preferred to use?</li>
<li>What are pros and cons of using stored procedures?</li>
</ol>

Stored procedures in Ruby on Rails

数据库

我是一个有6年经验的.net用户。最近，我开始从事ROR项目，并意识到存储过程/sql函数根本没有被使用。在询问时，我了解到这是一种常见的做法，通常团队中根本没有人编写sql查询，所有的事情都是使用ActiveRecord完成的。我在谷歌上搜索了所有可能的原因，但没有找到太多信息。所以我只是好奇地想知道不首选使用存储过...

问Ruby on Rails中的存储过程
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Ruby on Rails中的存储过程EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Ruby on Rails中的存储过程
EN