Questions tagged «database»

在过去的两家公司中，我曾经使用过REST API，用于通过Web应用程序查询数据。即。而不是让Web应用程序直接执行SQL，而是调用REST API，然后执行SQL并返回结果。 我的问题是...为什么要这样做？ 如果它要暴露给第三方，我可以理解。比完整的数据库更好地公开有限的REST API。但是在这两家公司中并非如此。 有人向我建议，这些REST API使在DBMS之间进行切换更加容易。但这不是数据库抽象层（DBAL）的重点吗？也许您将ORM用作DBAL，或者您可能只编写原始SQL并让DBAL在适当的情况下转换特定于DB的内容（例如，将MySQL的LIMIT转换为MSSQL的TOP）。 无论哪种方式，对我来说似乎都是不必要的。而且我认为这也使诊断问题变得更加困难。如果Web应用程序上的报告给出了错误的数字，则您不仅可以转储SQL查询，还必须转储REST URL，然后进入用作REST API的项目，并从中提取SQL。因此，这是一个额外的间接层，减慢了诊断过程。

32 database  web-applications  rest  web-api 

Windows / Linux为什么不使用关系数据库（RDBMS）？ 我知道他们使用文件系统来存储所有数据，但是您不认为像在网站/ Web应用程序中那样使用数据库会更有效吗？ 请详细说明如何通过数据库使用文件系统进行存储。 这与“ 何时应优先使用数据库而不是从文本文件中解析数据”相重复？我仅在操作系统上下文方面进行讨论，而这个问题是笼统的。

32 database  windows  linux  operating-systems 

我有以下问题：我的数据库包含超过200万条记录。每个记录都有一个字符串字段X，我想显示一个记录列表，其中字段X包含某个字符串。每条记录的大小约为500字节。 更具体地说：在我的应用程序的GUI中，我有一个文本字段，可以在其中输入字符串。在文本字段上方，我有一个表，显示与文本字段中的字符串匹配的（前N个，例如100个）记录。当我在文本字段中键入或删除一个字符时，表内容必须即时更新。 我想知道是否存在使用适当的索引结构和/或缓存的有效方法。如上所述，我只想显示与查询匹配的前N个项目。因此，对于足够小的N来说，从数据库中加载匹配项应该不是大问题。此外，在主存储器中缓存项目可以使检索更快。 我认为主要问题是在给定模式字符串的情况下如何快速找到匹配项。我可以依靠某些DBMS工具，还是必须自己构建一些内存索引？有任何想法吗？ 编辑 我已经进行了第一次实验。我已将记录分为不同的文本文件（每个文件最多200条记录），并将文件放在不同的目录中（我使用一个数据字段的内容来确定目录树）。我最终得到大约40000个目录中的大约50000个文件。然后，我运行Lucene来索引文件。使用Lucene演示程序搜索字符串非常快。拆分和建立索引花费了几分钟：对于我来说这完全可以接受，因为它是我要查询的静态数据集。 下一步是将Lucene集成到主程序中，并使用Lucene返回的命中将相关记录加载到主存储器中。

32 database  algorithms  data-structures  indexing 

我有一个客户正在寻求构建处理非常敏感的数据（比银行/卡详细信息更敏感）的网站/移动应用/桌面应用。由于数据的敏感性，他们不想将其保存在中央数据库中，但他们仍然希望其应用程序进行同步（假设我将一些数据添加到了移动应用程序中，然后我希望能够转到我的移动应用程序中。桌面应用程序并看到相同的数据）。 我想不出一种不错的，可靠的方法来做到这一点，我不确定是否有一种方法。这就是为什么我在这里。有谁知道我该如何处理这些数据？ 我正在考虑的一种解决方案是在每个应用程序上都有一个客户端数据库，该数据库将以某种方式在应用程序之间进行同步，我可以看到这是非常不可靠的，而且变得混乱。

31 database  web-applications  database-design  synchronization 

考虑一个电子商务网站，其中Alice和Bob都在编辑产品清单。爱丽丝（Alice）正在改善描述，而鲍勃（Bob）正在更新价格。他们开始同时编辑Acme Wonder Widget。鲍勃首先完成并用新价格保存产品。爱丽丝花了更长的时间来更新描述，完成后，她用新描述保存产品。不幸的是，她还用原先的价格覆盖了价格，这是不希望的。 以我的经验，这些问题在Web应用程序中极为常见。某些软件（例如Wiki软件）确实对此具有保护作用-通常第二次保存失败，并显示“页面在编辑时已更新”。但是大多数网站都没有这种保护。 值得注意的是，控制器方法本身就是线程安全的。通常，他们使用数据库事务，从某种意义上说，如果爱丽丝和鲍勃试图在同一时刻进行保存，就不会造成损坏，这使它们变得安全。竞争条件是由Alice或Bob在浏览器中拥有过时的数据引起的。 我们如何预防这种比赛条件？我特别想知道： 可以使用哪些技术？例如，跟踪上次更改的时间。各自的优缺点是什么。 什么是有用的用户体验？ 此保护内置哪些框架？

31 database  web-applications 

我在一家仅使用存储过程进行所有数据访问的公司工作，这使我们的本地数据库保持同步非常烦人，因为每次提交都必须运行新的proc。过去，我曾经使用过一些基本的ORM，但是我发现使用它的经验要好得多，更干净。我想向开发经理和团队中的其他成员建议我们考虑使用某种ORM进行未来开发（团队中的其他成员仅熟悉存储过程，而从未使用过其他东西）。当前的体系结构是.NET 3.5，类似于.NET 1.1，具有“神类”，它们使用ActiveRecord的奇怪实现并返回在代码隐藏文件中循环的未类型化数据集-这些类的工作方式如下： class Foo { public bool LoadFoo() { bool blnResult = false; if (this.FooID == 0) { throw new Exception("FooID must be set before calling this method."); } DataSet ds = // ... call to Sproc if (ds.Tables[0].Rows.Count > 0) { foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString(); // other properties set …

31 c#  database  orm  stored-procedures 

我真的不喜欢“ NoSQL”这个名字，因为它不是很具描述性。它告诉我数据库不是什么，我对数据库是什么更感兴趣。我真的认为该类别实际上包含数据库的几个类别。我只是想大致了解每个特定数据库最适合的工作。 我想做出的一些假设（并要求您做出）： 假设您有能力雇用任何数量的优秀工程师，这些工程师对已经存在的每种数据库技术都具有同等的经验。 假设您具有支持任何给定数据库（包括可以支持该数据库的可用服务器和系统管理员）的技术基础架构。 假设每个数据库都免费提供最佳支持。 假设您有100％来自管理层的支持。 假设您有无数金钱可以解决这个问题。 现在，我意识到上述假设消除了选择数据库时涉及的许多有效考虑因素，但是我的重点是在纯粹的技术层面上确定哪​​种数据库最适合该工作。因此，考虑到上述假设，问题是：每个数据库（包括SQL和NoSQL）对哪些作业而言是最佳工具，为什么？

31 sql  database  nosql 

假设您的用户可以创建自己的基于Web的表单（文本框，选择框等），然后将其发布到Web上以供用户填写。 是否有人有资源或关于如何构建数据库以将其绑定到动态表单方面的建议？ 例如，您会为每个表单或给定表单的不同版本创建一个子表吗？

30 architecture  database  webforms 

我现在有一个客户，要求我开发学校注册系统。现在，这是我第一次遇到这种挑战。我创建的大多数过去的软件都没有那么复杂。 我知道你们大多数人都已经创建了复杂的软件，我只想就此提出建议。我应该先设计前端还是后端？ 谢谢！ 这是我前一段时间在互联网上找到的一篇文章的结论。只想分享 http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157 前端与后端开发人员（我的看法） 我个人的看法 同样，这是一个培训问题，一些广泛的笔画概括： 前端开发人员 通常没有CS学位，或者没有三级学校的CS学位。 使用与基本语言类似的语言（请参阅PHP是基本语言） 具有将photoshop文档转换为CSS / HTML / etc的视觉技巧。 由于使用无类型语言，因此对迭代编程具有较高的容忍度 后端开发人员 有CS学位或丰富经验 在他们的问题解决方法上趋向于我 不要介意花几天时间寻找一个正在泄漏的物体 尝试构建工具来解决问题

30 design  database  database-development  database-design  front-end 

为了讨论的目的，让我们考虑一个FourSquare方案。 情境 实体： 用户数 地方 关系： 签到：用户<->地点，很多对很多 朋友：用户<->用户，多对多 数据库设计 这些很可能有错误，请指出。 关系数据库管理系统 表格： 用户数 地方 签到（交界处） 朋友（交界处） 优点： CAP：一致性，可用性 缺点： CAP：分区容限，也称为分片 方案=不灵活的结构 复制不良？ 图形 对象： 用户数 地方 边缘： 朋友：用户<->用户 签到：用户->地点 包含时间戳 优点： CAP：一致性，可用性？ 无模式，易变的对象和边缘 图形遍历查询，例如： 聚类 寻找一群朋友 寻找类似人喜欢的餐厅 还有其他常见/有用的查询吗？ 缺点： CAP：分区容忍度？ 文件/物件 3个独立的数据库？ 用户数 朋友清单 签到 时间戳记 用户 地点 地方 优点： …

29 database  database-design  relational-database  document-databases  graph-databases 

我一直在浏览一些著名CMS的SQL转储，包括Drupal 7，Wordpress（一些非常旧的版本）以及一些基于Python的自定义应用程序。 所有这些转储都包含带有字符串标志而不是整数标志的数据。例如，一个职位的状态表示为published，closed或inherit不是1，2或3。 我在数据库设计方面的经验非常有限，并且从未尝试过使用简单的SQL，但是始终有人告诉我，应该对此类数据使用数字/整数标志。显然tinyint，与例如相比，在数据库中占用的空间要少得多varchar(9)。 那我想念什么呢？这不是浪费数据存储和数据冗余吗？如果这些列使用整数而不是字符串，浏览，搜索和索引编制会不会更快一些？

29 database  database-design  sql  strings 

我需要存储并能够查询一些非常大的时间序列数据。 数据的属性如下： 系列数：约12.000（1.2万） 全球数据点数量：每月约5000亿（五亿） 混合值类型：大多数数据点为浮点值，其余为字符串 采样周期：系列之间以及系列内的变量 时间戳：毫秒精度 数据保留期：数年，无衰减或下采样 数据存档需要近乎实时地构建，但是可以接受合理的延迟（〜1小时） 如果需要，可以重建过去的数据，但是成本很高 有时（但很少），需要更新一些过去的数据 预想查询的属性： 针对数据的大多数查询将是基于时间戳的查询；从一天到几个月/年不等。90％以上将是对最新数据的查询 其他需求： 解决方案必须像免费啤酒一样免费，最好是开源的 我最初的想法是将带有HDF5文件的 PyTables / Pandas 用作存储后端，而不是SQL数据库。 问题： 假设PyTables / Pandas是“最佳”途径，将数据拆分成多个HDF文件，每个文件跨越一个给定的时间，还是将所有内容都放入一个单独的文件中，然后再变得庞大会更好吗？ 我应该选择固定格式还是表格格式？对我来说，如果我每月保留一个HDF文件，则固定格式看起来还可以，因为这样一来，整个系列就可以放入RAM中，并且可以在内存中切片而不需要表格式索引。我对么 ？ 如果那不是最好的方法，那么我应该如何构造该数据存储或应该考虑哪些技术？我不是第一个处理存储大量时间序列数据的人，解决此难题的一般方法是什么？ 我考虑过的其他方法： 数组数据库：它们非常适合具有恒定采样周期的时间序列，因为您只需要存储数组的开始和结束时间以及采样周期，然后只需要数组本身中的值和索引即可。但是，由于序列本身具有可变的采样周期，因此我需要保持更紧密的timestamp-> value关系，我认为这不太适合数组DBMS。 标准SQL数据库，其中带有时间戳，paramID，值作为列，但根据其性质，它们为任何查询都请求大量磁盘I / O

27 database  python  performance 

我在几个项目中看到，开发人员更喜欢将基本用户信息保留在一个表中（电子邮件/登录名，密码哈希，屏幕名称），而将其余非必需用户概要文件保留在另一个表中（创建日期，国家/地区等）。所谓非必需，是指仅偶尔需要此数据。明显的好处是，如果您使用的是ORM，则查询较少的字段显然是好的。但是，然后您可以将两个实体映射到同一表，这将使您免于查询不需要的内容（同时更加方便）。有人知道将这些东西放在两个表中还有其他好处吗？

26 database  database-design 

这是一个开放式的问题，但我想提出一些意见，因为我成长于一个以内联SQL脚本为标准的世界，然后我们都非常了解基于SQL注入的问题以及sql当时多么脆弱在各处进行字符串操作。 然后是ORM的曙光，您在其中向ORM解释查询并让它生成自己的SQL，在很多情况下，这种查询不是最佳方法，但又安全又容易。有关ORM或数据库抽象层的另一个好处是，SQL是在考虑数据库引擎的情况下生成的，因此我可以将Hibernate / Nhibernate与MSSQL，MYSQL一起使用，而我的代码从未更改，它只是一个配置细节。 现在快速发展到今天，Micro ORM似乎正在赢得更多开发人员的支持，我想知道为什么我们似乎在整个内联sql主题上都掉头了。 我必须承认，我确实喜欢没有ORM配置文件的想法，并且能够以更优化的方式编写查询，但是感觉就像我向诸如SQL注入之类的旧漏洞敞开了怀抱，而且我也将自己束缚于一个数据库引擎，因此，如果我希望我的软件支持多个数据库引擎，则需要做更多的字符串黑客攻击，这似乎开始使代码变得不可读且更脆弱。（就在有人提到它之前，我知道您可以在大多数micro orms中使用基于参数的参数，这在大多数情况下都可以防止sql注入） 那么人们对此事有何看法？在这种情况下，我将Dapper用作微型ORM，在这种情况下将NHibernate用作常规ORM，但是在每个领域中的大多数情况都非常相似。 我所说的内联SQL是源代码中的SQL字符串。曾经有过关于源代码中SQL字符串的设计争论，这有损于逻辑的基本意图，这就是为什么静态类型的linq样式查询如此流行的原因，它仍然仅是一种语言，但是在一页中说C＃和Sql现在，您的原始源代码中混合了2种语言。为了澄清起见，SQL注入只是使用sql字符串的已知问题之一，我已经提到过可以通过基于参数的查询阻止这种情况的发生，但是我着重指出了在源代码中根植SQL查询的其他问题，例如缺少DB Vendor抽象以及在基于字符串的查询上丢失任何级别的编译时错误捕获功能，这些都是我们设法通过ORM的高级查询功能来解决的问题， 因此，我不太关注各个突出的问题，而更全局的是，由于大多数Micro ORM使用这种机制，现在再次将SQL字符串直接再次包含在源代码中变得越来越容易被接受。 这是一个类似的问题，它具有一些不同的观点，尽管更多是关于没有微规范上下文的内联sql： /programming/5303746/is-inline-sql-hard-coding

26 database  sql  orm 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我需要在新网站中保留用户名。 这些通常分为三类 1）没有一个人名（例如：admin，user，service，help，root等） 2）我们可能想保留的超级著名人物或公司的名称 3）我们直接指定的其他名称。 如果前两个类别的用户名列表存在于某个地方，我可以使用它们，那将非常有帮助。 有人知道这样的名单吗？

26 database  design  data  api-design