mar*_*ext 57 sql database database-design data-structures
我不太确定stackoverflow是一个普遍问题的地方,但让我们试一试.
由于需要在某处存储应用程序数据,我总是使用MySQL或sqlite,因为它总是这样做.由于整个世界似乎都在使用这些数据库(大多数软件产品,框架等),像我这样的初级开发人员很难开始考虑这是否是一个好的解决方案.
好吧,假设我们的应用程序中有一些面向对象的逻辑,并且对象以某种方式相互关联.我们需要将此逻辑映射到存储逻辑,因此也需要数据库对象之间的关系.这导致我们使用关系数据库,我很好 - 简单来说,我们的数据库表行有时需要引用其他表的行.但为什么要使用SQL语言与这样的数据库进行交互？
SQL查询是一条短信.我可以理解这对于实际理解它的作用很酷,但是对于部署之前没有人见过的应用程序的一部分使用文本表和列名称是不是很愚蠢？如果您必须从头开始编写数据存储,那么您将从未使用过这种解决方案.就个人而言,我会使用一些'编译的数据库查询'字节码,它将在客户端应用程序中组装一次并传递给数据库.它肯定会用id号命名表和冒号,而不是ascii-strings.在表结构发生变化的情况下,可以根据新的db模式重新编译这些字节查询,存储在XML或类似的东西中.
我的想法有什么问题？我有什么理由不自己编写并使用SQL数据库吗？
编辑让我的问题更清楚.大多数答案都声称SQL是一种文本查询,可以帮助开发人员更好地理解查询本身并更容易地调试它.就个人而言,我还没有看到人们手工编写SQL查询一段时间.我认识的每个人,包括我,都在使用ORM.这种情况,我们建立一个新的抽象级别来隐藏SQL,导致思考我们是否需要SQL.如果你能提供一些不使用ORM而使用SQL的例子以及原因,我将非常感激.
EDIT2 SQL是人与数据库之间的接口.问题是为什么我们必须将它用于应用程序/数据库交互？我仍然要求人类编写/调试SQL的例子.
Don*_*nie 43
我认识的每个人,包括我,都在使用ORM
奇怪.我认识的每个人,包括我,仍然手工编写大部分SQL.与使用生成的解决方案相比,您通常会获得更严格,更高性能的查询.而且,根据您的行业和应用,这种速度确实很重要.有时很多.是的,我有时会使用LINQ进行快速n-dirty,因为我并不十分关心生成的SQL是什么样的,但是到目前为止,没有什么能够自动打败手动调优的SQL,以便在高性能数据库中实现高性能负载环境真的很重要.
Jay*_*Jay 24
如果您只需要将某些应用程序数据存储在某个地方,那么通用RDBMS甚至SQLite可能会过度.在某些情况下,序列化对象并将它们写入文件可能更简单.SQLite的一个优点是,如果你有很多这类信息,它都包含在一个文件中.缺点是阅读起来比较困难.例如,如果将数据序列化为YAML,则可以使用任何文本编辑器或shell读取该文件.
就个人而言,我会使用一些'编译的数据库查询'字节码,它将在客户端应用程序中组装一次并传递给数据库.
这是一些数据库API的工作方式.查看静态SQL和预准备语句.
我有什么理由不自己编写并使用SQL数据库吗？
如果您需要许多功能,那么在某些时候使用现有的RDMBS会更容易从头开始编写您自己的数据库.如果您不需要许多功能,更简单的解决方案可能更明智.
数据库产品的重点是避免为每个新程序编写数据库层.是的,现代RDMBS可能并不总是适合每个项目.这是因为它们的设计非常通用,因此在实践中,您将始终获得不需要的其他功能.这并不意味着拥有自定义解决方案会更好.手套并不总是需要完美贴合.
更新:
但为什么要使用SQL语言与这样的数据库进行交互？
好问题.
答案可以在1970年由IBM出版的EF Codd描述大型共享数据库的关系模型关系模型的原始论文中找到.本文描述了当时现有数据库技术的问题,并解释了为什么关系模型更优越.
使用关系模型的原因,以及像SQL这样的逻辑查询语言,是数据独立性的原因.
数据独立性在论文中定义为:
"......应用程序和终端活动与数据类型增长和数据表示变化的独立性."
在关系模型之前,数据库的主导技术被称为网络模型.在这个模型中,程序员必须知道数据的磁盘结构并手动遍历树或图.关系模型允许人们针对概念或逻辑方案编写查询,该查询独立于磁盘上数据的物理表示.逻辑方案与物理模式的分离是我们使用关系模型的原因.有关此问题的一个多,这里是从数据库类的一些幻灯片.在关系模型中,我们使用基于逻辑的查询语言(如SQL)来检索数据. Codd的论文详细介绍了关系模型的好处.给它一个阅读.
SQL是一种查询语言,与研究论文中通常使用的查询语言相比,它易于键入计算机.研究论文通常使用关系代数或关系演算来编写查询.
总之,我们使用SQL,因为我们碰巧使用关系模型来处理数据库.
如果您了解关系模型,就不难理解为什么SQL就是这样.基本上,您需要更深入地研究关系模型和数据库内部,以真正理解我们使用SQL的原因.否则它可能有点神秘.
更新2:
SQL是人与数据库之间的接口.问题是为什么我们必须将它用于应用程序/数据库交互？我仍然要求人类编写/调试SQL的例子.
因为数据库是关系数据库,所以它只能理解关系查询语言.在内部,它使用类似语言的关系代数来指定查询,然后将其转换为查询计划.因此,我们以我们可以理解的形式(SQL)编写查询,DB采用我们的SQL查询并将其转换为其内部查询语言.然后它接受查询并尝试查找用于执行查询的"查询计划".然后它执行查询计划并返回结果.
在某些时候,我们必须以数据库理解的格式对查询进行编码.数据库只知道如何将SQL转换为其内部表示,这就是为什么在链中的某个点始终存在SQL.这是无法避免的.
使用ORM时,只需在SQL上添加一个图层即可.SQL仍然存在,它只是隐藏.如果您有一个更高级别的层来将您的请求转换为SQL,那么您不需要直接编写SQL,这在某些情况下是有益的.有时我们没有这样的层能够执行我们需要的各种查询,所以我们必须使用SQL.
Mil*_*kov 11
鉴于您使用了MySQL和SQLite,我完全理解您的观点.大多数DBMS都具有需要一些编程的功能,而您可以从数据库免费获取:
索引 - 您可以存储大量数据,并且仍然可以根据索引快速过滤和搜索.当然,您可以实现自己的索引,但为什么要重新发明轮子
数据完整性 - 使用级联外键等数据库功能可以确保整个系统的数据完整性.您只需要声明数据之间的关系,系统负责其余部分.当然,再次,你可以在代码中实现约束,但它更多的工作.例如,考虑删除,您必须在对象的析构函数中编写代码以跟踪所有依赖对象并相应地执行操作
能够使用不同的编程语言编写多个应用程序,在不同的操作系统上工作,有些甚至分布在整个网络中 - 所有这些都使用存储在公共数据库中的相同数据
通过触发器轻松实现观察者模式.在许多情况下,只有一些数据依赖于其他一些数据,并且它不会影响应用程序的UI方面.确保一致性可能非常棘手或需要大量编程.当然,您可以使用对象实现类似触发器的行为,但它需要比简单的SQL定义更多的编程
MBC*_*ook 10
这里有一些很好的答案.我会尝试加两分钱.
我喜欢SQL,我可以很容易地想到它.由数据库顶层(如ORM框架)生成的查询通常是可怕的.他们会选择大量额外的东西,加入你不需要的东西等等; 所有这些都是因为他们不知道您只需要此代码中的一小部分对象.当您需要高性能时,您通常最终会进入并在ORM系统中使用至少一些自定义SQL查询,以加快一些瓶颈.
为何选择SQL？正如其他人所说,这对人类来说很容易.它是一个很好的最低共同点.任何语言都可以在必要时创建SQL并调用命令行客户端,它们几乎总是一个很好的库.
解析SQL效率低吗？有些.语法非常有条理,因此没有大量的歧义会使解析器的工作变得非常困难.真实的是解析SQL的开销基本上没什么.
假设你运行一个类似"SELECT x FROM table WHERE id = 3"的查询,然后再用4,然后5,一遍又一遍地再做一遍.在这种情况下,可能存在解析开销.这就是你准备好陈述的原因(正如其他人提到的那样).服务器解析一次查询,并且可以交换3和4以及5,而无需重新解析所有内容.
但那是微不足道的.在现实生活中,您的系统可能会加入6个表,并且必须提取数十万条记录(如果不是更多).它可能是一个让您在数据库集群上运行数小时的查询,因为这是在您的情况下执行操作的最佳方式.即使执行只需要一两分钟的查询,与从磁盘中提取记录和进行排序/聚合/等相比,解析查询的时间基本上是免费的.与发送特殊编码字节0x3F相比,发送ext"LEFT OUTER JOIN ON"的开销只有几个字节.但是当你的结果集是30 MB(更不用说gigs +)时,与不必混淆一些特殊的查询编译器对象相比,那些额外的字节是没有价值的.
许多人在小型数据库上使用SQL.我与之互动的最大的只有几打演出.SQL用于从微小文件(如小型SQLite DB)到TB级Oracle集群的所有内容.考虑到它的强大功能,它实际上是一个令人惊讶的简单和小型命令集.
但为什么要使用SQL语言与这样的数据库进行交互？
我认为这与您使用人类可读(源代码)语言与编译器交互的原因相同.
就个人而言,我会使用一些'编译的数据库查询'字节码,它将在客户端应用程序中组装一次并传递给数据库.
这是数据库的现有(可选)功能,称为"存储过程".
编辑:
如果你能提供一些不使用ORM而使用SQL的例子以及原因,我将非常感激
当我实现自己的ORM时,我使用ADO.NET实现了ORM框架:并且使用ADO.NET包括在其实现中使用SQL语句.
在所有编辑和注释之后,问题的主要观点似乎是:为什么SQL的本质更接近于人/数据库接口而不是应用程序/数据库接口？
对这个问题的简单回答是:因为这正是它最初的目的.
SQL的前身(QUEL可能是最重要的一个)的目的正是:一种QUERY语言,即没有任何INSERT,UPDATE,DELETE的语言.
此外,它旨在成为任何用户都可以使用的查询语言,只要用户知道数据库的逻辑结构,并且显然知道如何用他正在使用的查询语言表达该逻辑结构.
QUEL/SQL背后的原始思想是使用"任何可想到的机制"构建数据库,"真正的"数据库实际上可以是任何东西(例如,一个巨大的XML文件 - 尽管'XML'不被视为有效选项当时),并且会有"某种机制"理解如何将"任何事物"的实际结构转换为SQL用户所感知的逻辑关系结构.
事实上,为了实际实现这一点,底层结构需要自己"以关系方式查看它们",在那些日子里现在还没有被理解.
是的,必须编写SQL语句来存储和检索对象是很烦人的.
这就是为什么微软将诸如LINQ(语言集成查询)之类的东西添加到C#和VB.NET中,以便使用对象和方法而不是字符串来查询数据库.
大多数其他语言都有类似的成功,取决于该语言的能力.
另一方面,了解SQL如何工作是有用的,我认为完全保护自己是错误的.如果您不假思索地使用数据库,则可以编写效率极低的查询并错误地索引数据库.但是,一旦您了解了如何正确使用SQL并调整了数据库,您就拥有了一个非常强大且久经考验的工具,可以非常快速地找到您需要的数据.