程序大部分逻辑可以用 sql 来实现，不知道和用代码实现哪种更有效率

所以 linq 出来了

linq 只用于数据库，这个是绝大多数程序逻辑，都可用用 sql 语法，实现

LINQ 可以写成链式调用，也可以写成表达式，所以你们觉得哪种更有效率呢？

用 SQL 实现的意思，就是你写一个字符串，然后框架实现一个解析器，分析你的代码，然后转换成原本应该由你来写的代码，再执行。

@wizardforcel LINQ 的两种写法编译出来的结果是相同的，所以运行效率相同。
至于编写效率，当然跟你熟悉哪种结构有关，你熟悉函数式语句的当然是 Lambda 方便，熟悉 SQL 的当然是 SQL Form 方便咯。

场景不同，没啥好比较的，折腾个导数据，肯定 sql 快，折腾复杂逻辑，比如多维度，数据库需要几百个表才能实现的，你看那个快？

几百个张表的，可以类比下， List<List<List<List<List<List<?>>>>>>

@notreami 网站和 app ，逻辑都简单， sql 可以实现， app 除了界面没有多少业务

这个 sql ，其实可以代替 orm ，

@smdxex 我记得…… orm 不是用来代替 sql 的么……

有长期项目维护经验的人一般都会把代码尽量挪到容易维护的地方，效率是其次。

@yidinghe 你不认为 sql 是比任何高级语言，抽象层次更高级吗

@smdxex 语法贴近自然语言不意味着抽象层次就高。 SQL 可维护性差表现在：标准的 SQL 不足以用来开发复杂的逻辑，必需要用到数据库特定的语法，也就是说 SQL 不是一个语言而是一系列语言，学习成本极高。而且这样的业务逻辑就算写出来，将来找谁交接都是个问题，大部分人只会标准 SQL 。

sql 不是图灵完毕的吧

@whatTheGhost 不完备是没有关系得，这个必须有高级语言代码配合，只不过抽象了一些列逻辑

高级语言函数调用写在查询内部，比较像 link ，
按照需求，还应该有并列链式结构，＝＞不仅有传参数意思，还有顺序结构意思，管道

linq

@smdxex 你说了半天其实就是在说函数式风格编程咯。这和 SQL 有啥关系。

@msg7086 很多程序逻辑就是集合操作， sql 抽象了这个集合操作，解析成代码

@smdxex 难道不是函数式风格编程能用来集合操作，而 SQL 只是其中的一种实现吗？
LINQ 本身就是函数式风格编程， LINQ SQL Form 是函数式编程的 SQL 转写表达。

以下是你那些 SQL 代码的 Ruby 函数式风格转写：

INSERT arr 9 x = rownumber, y = 9

9.times { |x| arr << {x: x, y: 9} }

SELECT x,y=>drawPoint(x,y) FROM arr

arr.each { |x:, y:| draw_point(x, y) }

SELECT count (*) > 1 arr a INNER JOIN arr j ON (a.x=j.x) AND (a.y=j.y)

arr.group_by(&:itself).select{ |point, group| group.size > 1 }.keys

@msg7086 现在没有人在逻辑中使用， group ， select 等在 c#， java ，等语言中，
arr.group_by(&:itself).select{ |point, group| group.size > 1 }.keys
这个是说处理集合得话，我得意思就是这样，但是包括链接查询和所以 sql 可以处理集合

@smdxex 那就……用个好点的语言呗？
C#的 LINQ 是支持 Group 和 Select 的（分别是 #GroupBy 和#Where ）， Java 不懂就不说了。
所以我之前就说了，你说了半天的 SQL 其实只是函数式风格编程的某种表达，你的关注点应该在函数式风格上，而不是 SQL 上。
现在我们做开发都已经不写 SQL 语句了，都是用函数式风格来写逻辑，然后交给 ORM 去转译成对应的 SQL 。
直接写 SQL 其实开发效率是偏低的。

@msg7086 你没有搞懂我得意思，你一直说得是操作数据库得逻辑，我说得是，一切可以程序逻辑，可以用 sql 类似语句
来表达，比如，我弄了好几个游戏，发现这些游戏 6-7 成逻辑，可以写成 sql 语句来表达， sql 抽象度更高，所以效率更高

@smdxex 是你没有搞懂我的意思。
我上面根本就没有提到任何一个数据库，示例的操作全都是在数组上进行的。
你如果把你那些 SQL 语句都写成函数式表达，你会发现不仅抽象度好，而且表达力更强，开发效率比 SQL 更高。

SQL 的表达力已经很弱了，所以 Rails 框架才把 SQL 抽象起来，更好地用代码来表达。
而你现在等于是在开倒车，倒退回用 SQL 的年代。

@msg7086 我得意思是，这种 sql ，可以代替
90%循环，但是我从来没有听说过，不写循环得程序

@smdxex
再举个栗子好了，假设有如下的本地变量和类型：
Gamedata = {Mob, Persons}
Person = {HP, MP, Money, Bag}
Bag = [Items]
Item = [Name, Count]

现在要找出所有身上带着至少 5 个大师球的所有玩家。

你眼中别的程序员的代码：
MatchedPersOns= []
for i = 1 to Gamedata.Persons.size
..person = Gamedata.Persons[i]
..items = person.Bag
..count = 0
..for j = 1 to items.size
....item = items[j]
....if item.Name == '大师球'
......count = item.Count
..if count >= 5
....MatchedPersons += person

你眼中的代码：
SELECT DISTINCT Persons FROM Gamedata.Persons JOIN Items
WHERE Persons.id = Items.person_id AND Item.Name = '大师球' AND Item.Count > 5

别人眼中的代码：
Gamedata.Persons.select { |p| p.Bag.any? { |i| i.name == '大师球' && i.count > 5= } }

如果你没听说过，那就去听说一下呗……

上面代码手滑了，两处应该是 >= 5 。

@msg7086 以前你们根本没有发现， sql 这种表达方式，可以写游戏，写 app,写企业应用关系少得，本地应用，

@smdxex 哦嚯，你是全球第一个发现的啊，好棒哦。

反正我们早就淘汰这种低效率的表达方式了，你开心就好。

@msg7086 是你开心，聊以自慰就好吧

我说得这个东西，其实是微软很早前提出得， dsl 语言得，改进版本，换了一个表达方式，你们就自慰起来了？

你要是搞着玩，随便怎么方便怎么来，要是分布式应用，一般把逻辑放在代码里，就是尽量把压力放在应用端而不是数据库端，因为一般应用横向扩容比数据库扩容简单的多，出现问题了直接大不了重启，数据库要是挂了就不好玩了