标签：关系数据库

共 9 篇相关文章

IT 累计浏览 4,240

从需求出发来看关系模型与非关系模型–关系模型与非关系模型概述

这篇讲的是关系模型与非关系模型的选择根源。作者从当前对 NoSQL 的盲目追捧现象切入，指出许多项目初创团队都在纠结如何选择 NoSQL，却忽略了模型本身的本质。文章的核心是帮读者理清 RDBMS、NoSQL、CAP、BASE 这些概念的本源，并用一个“车”的例子清晰地对比了层次模型和关系模型的差异。关键在于，关系模型通过集合运算抽象了数据“关系”，让用户无需像层次模型那样关心从“车”到“轮子集合”再到“具体轮子”的存取路径，只需关注查询逻辑本身，这使得它严谨且被广泛接受。然而，随着面向对象编程的普及，关系模型带来了“阻抗失配”问题——将对象中的继承、组合映射到关系表变得非常痛苦。为解决此问题，业界尝试了 ORM 工具、在数据库层支持对象，以及利用脚本语言的动态特性来简化映射。这些方案各有代价，ORM 学习成本高且易导致低效查询，而用 Map 则会破坏封装性。随着互联网发展，对高性能和灵活数据结构的需求，让层次模型的变种——NoSQL 重新受到关注。文章接下来将从具体应用场景出发，剖析关系模型在哪些地方力不从心，以及 NoSQL 为何又能满足新的需求。

IT 累计浏览 3,184

C Mohan 讨论NoSQL的得与失

这篇文章是资深数据库专家 C Mohan 从历史演进的视角，对 NoSQL 运动兴起背景及其暴露问题的系统性梳理。他首先指出了传统关系数据库在应对 Web 2.0 时代需求时的力不从心，比如难以建模社交图谱、JSON 数据交换不便、扩展性与成本制约，以及 ACID 原则在实际业务中常需妥协等。接着，作者结合自己在 System/38、Lotus Notes 乃至 DB2 等系统上的深刻教训，揭示了数据库内核设计的复杂性，例如锁粒度、崩溃恢复、集群支持等关键环节的挑战，为理解后续问题埋下了伏笔。随后，他犀利地剖析了 NoSQL 方案普遍存在的“先天不足”：对并发控制与原子性等事务核心问题关注不够，索引设计过于简单，数据模型复杂却缺乏标准化工具，以及对分布式下一致性和可靠性的误判。文章并未全盘否定 NoSQL，而是强调无论是 MongoDB 的写锁、CouchBase 的文档复制粒度，还是对 ACID 的简化处理，都在高并发或复杂业务场景下可能遇到瓶颈。最终，这篇讨论的启发在于：技术选型需回归具体场景的本质需求，无论是追求强一致的传统企业核心系统，还是需要灵活扩展的互联网应用，理解关系数据库与 NoSQL 各自的设计哲学和代价，才能避免盲目追随潮流，做出更务实的技术决策。

IT 累计浏览 3,183

PostgreSQL从菜鸟到专家数据库的数据存取设计

这篇讲的是，当你使用PostgreSQL时感觉“明明建了索引，查询还是慢”，问题可能出在数据存取的底层设计上。作者从一个常见的性能瓶颈场景出发，系统性地拆解了数据如何在磁盘与内存之间流转。文章深入到了PostgreSQL的行存与列存布局、MVCC机制下数据的多版本存储方式，以及TOAST大字段处理等具体实现层面。它没有停留在“建立合适索引”的通用建议上，而是解释了为什么选择B-tree或Hash索引、何时该用GIN索引处理JSONB，这些选择背后与表的填充因子、死元组清理（VACUUM）策略是如何紧密关联的。通过梳理从插入、更新到查询的全链路，文章阐明了存取设计是一个环环相扣的系统工程，一处不当就可能形成性能短板。对于希望从“会用”PostgreSQL走向“用好”的开发者，这篇文章提供了一张清晰的内部运作地图。

IT 累计浏览 3,497

PostgreSQL从菜鸟到专家 PostgreSQL介绍

这篇讲的是PostgreSQL这款开源关系型数据库的核心定位与核心优势。作者从“为什么需要PostgreSQL”出发，点明它并非简单的MySQL替代品，而是为了解决特定场景下的痛点而生——比如需要复杂查询、严谨事务支持，或是追求接近商业数据库的功能与性能。文章着重刻画了PostgreSQL的几个关键特质：它对SQL标准的高度遵从，提供了诸如窗口函数、CTE等高级特性；其MVCC（多版本并发控制）实现带来的读写互不阻塞的优势；以及极强的可扩展性，用户不仅能添加自定义类型与函数，甚至能通过扩展机制实现从时序数据处理到机器学习的多种功能。这些都让它能从容应对企业级应用、地理信息系统（GIS）以及数据仓库等多样化场景。文中也坦诚地讨论了学习曲线，指出其强大的背后是需要一定理解成本的。总体而言，这篇导读清晰地勾勒出PostgreSQL作为一个“全能型选手”的画像，适合那些不满足于基础功能、希望建立可扩展数据架构的开发者深入了解。

IT 累计浏览 2,730

PostgreSQL从菜鸟到专家什么是PostgreSQL数据库

这篇讲的是PostgreSQL这款数据库究竟是什么，以及它为何值得开发者关注。作者从PostgreSQL的核心定义切入：它是一个成熟、可靠且完全开源的关系型数据库管理系统，支持标准的SQL查询语言。文章没有停留在概念层面，而是用具体细节支撑：它可以在从FreeBSD、Linux到Windows的多种平台上运行，功能上涵盖了事务、子查询、外键、复杂锁乃至多版本并发控制等高级特性，性能基准测试可与商业产品一较高下。接着，文章回溯了其从1977年伯克利大学的Ingres项目演化至今的完整历史，这解释了它深厚的技术根基。在架构上，PostgreSQL采用经典的客户端/服务器模型，通过独立的服务器进程管理数据访问，这种设计保障了多用户环境下的数据完整性与安全性，并支持通过ODBC、JDBC等多种方式连接。文章还特别澄清了“开源”的真正含义：使用、修改和重新发布软件的权利（遵循类似BSD的宽松许可），以及背后活跃的社区和商业支持。这不仅是一篇入门指南，更完整展现了PostgreSQL作为开源数据库典范的全貌。

IT 累计浏览 3,170

数据库发展史知识普及

这篇讲的是数据库如何从早期系统一步步演化至今。作者梳理了几个关键阶段：从最早处理层级关系的层次型、网状型数据库，到CODD提出关系模型后开启的关系型数据库黄金时代，再到互联网时代为应对海量数据与高并发而兴起的NoSQL运动，以及后来试图融合两者优势的NewSQL。文章的重点不在于罗列技术名词，而在于揭示每种数据库范式是为解决哪类核心问题而生。比如，它对比了关系型数据库强一致性与事务保障的优势，与NoSQL为可扩展性与灵活性在一致性上做出的妥协，并解释了CAP理论在此过程中扮演的角色。同时，也提及了NewSQL如何试图利用新架构在分布式环境下重新提供SQL的完整功能。读下来，你能清晰看到技术选型背后的“为什么”——不同的数据模型、查询语言和系统设计，直接对应了从金融交易到社交网络等截然不同的应用场景。这篇文章将数据库的演进脉络与各阶段的技术取舍讲得比较明白，适合用来构建对这一领域的整体认知框架。

IT 累计浏览 2,583

Mysql 安全

这篇讲的是如何为MySQL数据库系统构建一套基础但关键的安全防线。作者指出，MySQL的多平台特性使其默认配置难以兼顾所有场景，因此用户必须在自定义环境中主动加固。文章从源码编译安装开始，系统梳理了从安装到配置的11个核心安全要点，操作性很强。作者强调，安全的首要原则是控制权限。这包括必须修改root空密码并使用强密码、删除默认的test库和匿名用户、以及将默认管理员名root改为不易猜测的用户名。配置层面，核心思路是“最小化”：使用非root的独立mysql用户运行服务，禁止远程连接（或至少修改默认端口），限制单个用户的连接数。同时，通过严格控制文件系统目录权限、清理命令历史记录、并在配置文件中禁用`LOAD DATA LOCAL INFILE`等危险功能，来堵住潜在的信息泄露和数据窃取漏洞。这些措施环环相扣，共同目标是收缩攻击面，确保数据库服务仅在受控的必要范围内运行。

IT 累计浏览 2,391

ERWin教程（包括如何注册）

这篇讲的是专业数据库设计工具ERWin与更通用的Visio之间的对比选择。作者从实际设计场景出发，指出虽然ERWin的学习曲线比Visio更陡峭，界面选项也更复杂，但在应对模型层次深、数据对象关系繁杂的大型项目时，ERWin的优势就显现出来了。它专注于ER模型设计，并提供了强大的数据库正向与逆向工程能力，能直接将设计转化为实际数据库或反向读取现有库结构，还能自动定义格式生成设计文档。这些功能是通用工具Visio难以企及的。对于追求设计严谨性和工程化落地的数据库开发者而言，ERWin显然是更趁手的利器。文章最后也附带了ERWin的具体注册步骤，为有需要的读者提供了入门指引。

IT 累计浏览 2,848

数据库设计范式的理解

从去年年底开始，作者与多位技术朋友就数据库设计和架构展开深入交流，发现一个普遍现象：不少开发者过分推崇ORM工具和数据库设计范式，将其视为设计的金科玉律，却忽视了技术必须服务于业务这一基石。这篇文章正是基于这些交流，分享作者对数据库设计范式的真实理解。文章指出，范式化设计虽能提升数据一致性和减少冗余，但若脱离业务场景，反而可能增加复杂度和开发成本。作者通过对比理论范式与实际业务需求，强调设计时应权衡范式优势与业务灵活性，避免为了范式而范式。例如，在读写性能要求高的系统中，适度反范式化能有效提升查询效率，而机械套用第三范式可能导致查询效率低下。核心观点是：数据库架构应从业务逻辑出发，让技术为业务赋能，而非反过来。对于正在构建数据层的开发者，这提醒大家回归业务本质，在范式与实践间找到平衡点——设计范式是手段，业务成功才是目标。