打个比方，如果我知道我管理的1000个数据库每天发生了多少张表的变更，哪些是人工触发的，哪些是程序触发的，如果我们知道，那么我们处理问题的时候会更加主动，而绝大多数情况下，其实我们是不知道的，或者说我们觉得不需要关注这些。
根据我们前面说的 Item 中的 Add Type 属性，这个主要用来标识输入的数据是不是随着时间的变化而变化，有下面 3 种选项。
维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实”，将环境描述称为“维度”，维度是用于分析事实所需要的多样环境。
一个表的设计，个人愚见，首先要看业务，以及你选择的架构，业务量是大还是小，业务是互联网性质的，还是传统性质的，业务是可变化较大的，还是比较固话的，等等，当然可能还有更细分的，从数据库的角度来看，你是准备使用哪种数据库，决定是可以分库分表，还是分区表，或者冷热表，在或者使用特殊的某些小手段，来让你的表更清爽一些。同时不同的数据库也赋予表设计更多的余地，所以我一直在希望开发和DBA能紧密结合，因为开发大部分是不知道各种数据库的门道，和一些奇特的功能，而DBA可能并未有开发人员的对业务理解的深刻，如果二者结合，则设计的表会比单方面设计的表要好的多。也更值得推敲。
数据仓库建模过程中，针对事务型事实表设计，经常会遇到维度属性选择的问题，比如客户维度，在操作型系统中，为了跟踪客户状态的变化，往往会附加客户记录的四个属性：
导读：Tableau是商业智能软件届的翘楚，对于制作各种可视化分析图表极为便捷。本文主要讲解用tableau制作各种多变折线图，包括凹凸图、弧线图和雷达图等。
在《容易引起雪崩的两个处理》里，我提到一个慢查询的问题。本文先从整洁架构的角度讲讲慢查询sql完成的功能以及设计，再介绍对sql进行的实施测试现象以及思考。
大家在写Go时有没有注意过，一个struct所占的空间不见得等于各个字段加起来的空间之和，甚至有时候把字段的顺序调整一下，struct的所占空间又有不同的结果。
在数据库设计中，选择合适的数据类型对于确保数据的有效存储和查询效率至关重要。对于需要存储文本信息的场景，我们常会使用VARCHAR类型。 然而，对于不同语言的字符，VARCHAR所能存储的数量会有所不同。
想做一个B2B2C的电商平台，在后台数据统计搭建的时候需要注意哪些问题？如何设计具体的统计模块？
做CMS最基本的一个功能就是做一个栏目导航，如果这个导航想做成动态的（即需要从数据库里提取数据）那么要如何实现呢？ 简单的方法——DataTable 一个表两个字段，把数据提取出来，放在DataTable里面，然后在页面里做一个循环，OK了。是不是很简单呢？如果看了我的代码，估计会有很多人提出异议，呵呵。这里就是想和大家详细讨论一下。 由于每个页面都要用导航，而且都是一样的，所以我建立一个UserControl（用户控件）来做这个导航。首先在.ascx页面里定义一个protected的Data
开发在使用MySQL中,建立比较大的VARCHAR字段来存储SQL执行的语句或者利用MYSQL 来存储什么VARCHAR(1000) VARCHAR(2000) 之类的事情比比皆是，实际上存储超高的字符的字段在MYSQL中是不提倡的,本来可以是JSON格式的数据，非要变成普通字段存储到MYSQL中，或者使用各种怪异的如下图那样的数据存储方式,有必要这样一根筋的这样处理字符吗？实际上MYSQL8本身支持JSON类型的数据输入,并且很容易处理这些信息
PostgreSQL 让人着迷的地方，不在于他比某些数据库的流行，也不在于比某些数据库的高“贵”， 更不如某些数据库的“简单”。Postgresql 让人无法自拔的是他的”多端变化”， 用开发的角度来说，叫多态性。
既然见到了公司，我们可以定义一个Class Company ，那么我们见到了字段，是不是也可以定义一个Class ColumnInfo呢？ 公司的描述信息类： 代码 public class Company { public int CompanyId { get; set; } public string CompanyName { get; set; } public string Province { get; set; }
今天在生产环境中,开发人员提交了一个脚本，是做update操作的，但是update操作的时候过滤条件有些大，本来预计修改的数据只有5000条，结果这个语句运行下来更改了500万条数据。对生产系统来说算是一个数据灾难，赶紧和开发确认了问题发生的时间，结果说是在半夜11点多，刚好在后半夜才开始做数据备份，这样这个变更也同时影响了备份，就算做紧急的数据恢复也是没有任何效果的。目前采用的备份都是全量的按天备份，备份收到影响，恢复还是比较困难的。 这个问题就在紧急的讨论中分为了两个步骤，我来尝试恢复昨天备份前的数据，
聊一个实际问题：淘宝的数据库，主键是如何设计的？ 某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显 的错误就是关于MySQL的主键设计。
Apache Lucene是ElasticSearch使用的全文检索库。了解Lucene之前，需要先了解一些概念：
2.POST 可以附加 body，可以支持 form、json、xml、binary等各种数据格式；
此篇的开始之前，默哀3分钟，某些伟大的凡人不是他位高权重，也不是他能一句话使整个世界停转，而是 陌生人 想起他，从心底为他的离去感到伤心，哪怕只有一秒。
此文承接第一篇《进一步了解S/4 HANA系统》，上一篇对S/4 HANA整体了解，这一篇我们来了解一下系统表的变化。
本文的设计方法主要应用于大型综合数据分析系统，由于其接入数据源种类较多且数据不稳定。所谓不稳定是指数据进入数据仓库后，外部数会发生变化，关键是这些变化会影响整体的数据分析。一般的数据仓库中采集的各种数据聚合策略，聚合后的数据能够提升整体的分析效率，但聚合后的数据更新的成本极高，会产生链条式的反应，影响一波又一波的数据。双外键的设计主要是应对这类不稳定的数据源，针对数据来源多样化、数据源无法受到自身约束的数据分析系统。
作者： 陈勃，文艺青年一枚。产品策划岗供职6年。写得了文档，编得了文章，做得了诗词，玩得了金属。 经常和开发（简称开发gg）开玩笑说，产品经理是一个高危职业，随时面临着被砍、被炒、被集体攻击、被要求请吃饭等，真是用绳命（生命）在工作。对此多少让人有些啼笑皆非。 但是玩笑归玩笑，仔细想想，产品经理面临的这种种“威胁”，从两方面提高注意力，应该能够避免：一方面是自身能力问题，更重要的一方面，是要考虑自身和外界的沟通问题。 本文主要是想和大家分享一下自身和外界沟通这方面，我对于“产品经理和开发gg沟通”这个问题的
Vue3 已经更新到 RC9，正式发布在即，其中让人倍加关注的重大更新：组装式 API (Composition API) 到底是什么，相比 Vue2 又有什么优势呢？
我最近参与了公司的一个新项目，需要通过openapi接口把接入方的数据，比如：企业、订单、合同、物流等，同步到我们平台，然后我们平台给他们提供金融能力。
一个好的可视化工具一定要有层次管理和交互设定的功能，让我们能够从不同的角度对数据进行切换分析，PowerBI很好的实现了这两项。
索引被用来快速找出在一个列上用一特定值的行。没有索引，MySQL 不得不首先以第一条记录开始，然后读完整个表直到它找出相关的 行。表越大，花费时间越多。 添加索引是给某一个字段，或者说某些字段添加索引。
◆背景介绍 2020年6月，商品系统从SAP、中间层等接入的商品数据越来越多且更新频繁，商品数据库主从更新数据量大，约每分钟54万多条更新，约八分钟就会产生大于1G的Binlog文件，在数据库IO能力一定的情况下，发生数据同步延迟，影响写入与读出的及时性，进而影响到商品基础系统的可用性。 如果仅是从翻阅代码的角度去分析，会花费大量人力。抛开系统本身，当商品多个应用都在读写商品库，并在数据库层起到数据汇总和集中反馈的情况下，分析这个点是一个较好的方向。 ◆分析模型 把Binlog解析成Sql 纯文本，解析出来
某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显的错误就是关于MySQL的主键设计。
1.在关系模型中，实现“关系中不允许出现相同的元组”的约束是通过 “主键” 完成的。
前端的发展太快了，前端框架和技术的发展也层出不穷，还包括不同智能设备的出现，对前端开发同学来说是个很大的跳转，简单列举下：
事情的发生时这样的，在很久很久以前，SQL SERVER 有一个字段类型叫timestamp， 对比其他数据库都没有的 row version 自动化管理的东西。这个东西厉害的地方，虽然看上去可能是一个时间字段，但实际上不是，只要你对SQL SERVER 表的任意一行进行变动，那你放心那个字段的值一定会自动变化，这样你就可以通过这个字段，在程序里面先将这行的 timestamp值取出来，然后根据业务逻辑，如果需要过段时间你再去这一行变化或曾经变化过吗？之间与现在的timestamp字段值进行比对，那妥妥的能告诉你，这行的数据任意字段是否变化过，有人说MYSQL也有timestamp ，那个字段是通过时间来update 只要这个行变动过就触发timestamp 更改时间就可以了，当然datetime也行，早期版本不行。
作为一个程序猿，对造轮子这事情可以说是情有独钟，几乎程序猿内心都存在一个梦想是去将开源的技术都实现一遍，所有从本篇开始，我会开一个造轮子系列。
在本系列的第一部分中，我们定义了数据治理并研究了导致大规模清理项目的失误。在这篇文章中，我们将研究常见的数据治理模型，哪些模型最适合不同类型的组织。
本文将重点探讨数据处理层中数据仓库的建设。早期的数据服务中存在不少问题，虽然在做运营Dashboard系统时，对后台数据服务进行了梳理，构建了数据处理的底层公共库等，但是仍然存在一些问题：
一、前言 为深入研究P4语言相关规范及运行操作使用，本系列文章根据P4.org网站给出的《The P4 Language Specification v1.0.2》[1]内容，并通过我们的运行使用的具体实例和分析汇总，希望能为大家研究P4提供一点参考。 作为大二和大三的本科生，水平和经验有限，感谢SDNLAB提供平台，希望能和大家相互学习交流。 本系列文章分为三个部分，系列一 翻译和阐述 P4.org网站给出的《The P4 Language Specification v1.0.2》的第二部分首部及字段；
每种数据库都有自己的特色，SQL SERVER 也有自己的招数，timestamp字段类型会针对于行中任何列值的变化，而改变，之前也写过PG 怎么来模拟这个功能
RSTP的端口角色共有4种：根端口、指定端口、Alternate端口和Backup端口。
有一种说法，生命中唯一不变的东西就是变化。这同样适用于数据库模式。我们会想要获取我们曾经认为不需要的信息。或者一些新上线的服务需要包含在数据库记录中。不管变更背后的原因是什么，一段时间之后，我们不可避免地需要对应用程序中的底层模式设计进行更改。虽然这经常会在传统的表格数据库系统中带来一些挑战甚至是麻烦，但在MongoDB中，我们可以使用模式版本控制来简化这一过程。
前段时间给大家分享了阿里的数仓建设《阿里数据仓库研发规范》,本文主要讲解下创业型公司是如何建设数仓的。本文将重点探讨数据处理层中数据仓库的建设，有提到早期的数据服务中存在不少问题，虽然在做运营Dashboard系统时，对后台数据服务进行了梳理，构建了数据处理的底层公共库等，但是仍然存在一些问题：
在微服务架构下，多个服务之间通常会定义明确上下游关系，下游系统可以依赖上游系统，下游系统可以通过API查询或修改上游系统的数据；反过来则不然，上游系统不应该知道下游系统的存在，也就是说上游系统不能依赖下游系统，上游系统的变化只能通过异步事件的方式发出，下游系统监听事件并基于事件做对应的数据状态变化。
下表是MySQL常见的存储引擎InnoDB，MyISAM和Memory分别支持的索引类型
维度表是维度建模的灵魂所在，在维度表设计中碰到的问题（比如维度变化、维度层次、维度一致性、维度整合和拆分等）都会直接关系到维度建模的好坏，因此良好的维表设计就显得至关重要，今天就让我们就一起来探究下关于维表设计的相关概念和一些技术。
1、不管是做需求还是测试，都应该考虑整个链路，确保兼容性或者其他模块不受影响。比如内容创作改动，应该考虑到审核侧、内容分发侧是否正常。
围绕着维度建模，那就不得不了解，早期的数据仓库构架方法。这里介绍一下两个经典的数仓架构理论。
ps：modify只能改字段数据类型完整约束，不能改字段名，但是change可以！
一个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序] 所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
