关系模型

Django之ORM表间操作 之前完成了简单的数据库数据增加操作。这次学习更多的表间操作。 单表操作 增加 方式一 b = Book(title="Python基础", publication_date="2019-10-15", price=20) b.save() 这是我们之前增加数据的方式，是用实例化对象的方式来添加数据的，这是添加数据的一种方式，接下来，我们看看其他的添加数据的方式。 方式二 Book.objects.create(title="Python基础", publication_date="2019-10-15", price=20) 这种方式来添加数据，不需要创建变量来接收和使用save()保存就会直接将数据添加到数据库。 删除 方式一 b = Book.objects.get(title="Python基础") b.delete() 方式二 Book.objects.filter(title="Python基础").delete() 修改 方式一 book = Book.objects.get(name="天龙八部") book.name = "天龙八部2" book.save() 方式二 Book.objects.filter(name="天龙八部2").update(name="天龙八部") # 注意不能用get取值 这里注意，使用get取到的是一个对象

本文是Cassandra数据模型设计第一篇（全两篇），该系列文章包含了eBay使用Cassandra数据模型设计的一些实践。其中一些最佳实践我们是通过社区学到的，有些对我们来说也是新知识，还有一些仍然具有争议性，可能在要通过进一步的实践才能从中获益。 本文中，我将会讲解一些基本的实践以及一个详细的例子。即使你不了解Cassandra，也应该能理解下面大多数内容。 说说Cassandra在ebay的使用情况 我们尝试使用Cassandra已经超过1年时间了。Cassandra现在正在服务一些用例，涉及到的业务从大量写操作的日志记录和跟踪，到一些混合工作。其中一项服务是我们的“Social Signal”项目，支撑着ebay的pruduct pages里like/own/want特性。我们开发的一些用例已经上线运行，但更多的还是处于开发阶段。 我们的Cassandra集群规模并不庞大，但正在稳步的增长中。在过去几个月里，我们共部署了几十个节点，它们分布在几个跨机房的小型集群中。你可能会问，为什么要多个集群？我们通过的职能部门和业务来划分集群。相同职能部门的相同业务的用例共享一个集群，但它们存在于不同的keyspaces中。 RedLaser, Hunch和其它ebay的合作伙伴也在尝试cassandra解决现实中各种问题。除了Cassandra，我们也在使用MongoDB和Hbase

【编者注：InfoQ中文站获得了eBay工程师Jay Patel的授权，将会为陆续为读者呈现Cassandra数据模型设计的系列内容。】 本文是Cassandra数据模型设计第一篇（全两篇），该系列文章包含了eBay使用Cassandra数据模型设计的一些实践。其中一些最佳实践我们是通过社区学到的，有些对我们来说也是新知识，还有一些仍然具有争议性，可能在要通过进一步的实践才能从中获益。 本文中，我将会讲解一些基本的实践以及一个详细的例子。即使你不了解Cassandra，也应该能理解下面大多数内容。 说说 Cassandra 在 ebay 的使用情况 我们尝试使用Cassandra已经超过1年时间了。Cassandra现在正在服务一些用例，涉及到的业务从大量写操作的日志记录和跟踪，到一些混合工作。其中一项服务是我们的“Social Signal”项目，支撑着ebay的pruduct pages里like/own/want特性。我们开发的一些用例已经上线运行，但更多的还是处于开发阶段。 我们的Cassandra集群规模并不庞大，但正在稳步的增长中。在过去几个月里，我们共部署了几十个节点，它们分布在几个跨机房的小型集群中。你可能会问，为什么要多个集群？我们通过的职能部门和业务来划分集群。相同职能部门的相同业务的用例共享一个集群，但它们存在于不同的keyspaces中。 RedLaser,

信号 Django 提供一个“信号分发器”，允许解耦的应用在框架的其它地方发生操作时会被通知到。 简单来说，信号允许特定的sender通知一组receiver某些操作已经发生。 这在多处代码和同一事件有关联的情况下很有用。 内置信号 模型信号 django.db.models.signals模块定义了模型系统发送的一组信号。 pre_init django.db.models.signals.pre_init 每当您实例化Django模型时，该信号都会在模型的__init__()方法的开头发送。 带有此信号的参数： sender 刚创建了一个实例的模型类。 ARGS 传递给__init__()的位置参数列表： kwargs 传递给__init__()的关键字参数的字典： 例如： from app01 import models p = models.Publisher(name='沙河出版社') 发送到pre_init处理程序的参数将是： 参数 值 sender Publisher(类本身) ARGS [] （一个空列表，因为没有位置参数传递给 __init__() 。） kwargs {'name'： “沙河出版社 ” } pre_save django.db.models.signals.pre_save 这是在模型的save()方法的开头发送的。 带有此信号的参数：

第二部分 面向对象分析 2.1 面向对象分析(OOA)的定义？ 　　OOA——面向对象的分析，就是运用面向对象方法进行系统分析，对问题域(问题所涉及的范围)和系统责任(所开发的系统应具备的职能)进行分析与理解，找出描述问题及系统责任所需要对象，定义对象的属性、操作以及它们之间的关系。 2.2 面向对象分析(OOA)的优点？ 加强了了对问题域和系统责任的理解； 改进与分析有关的各类人员之间的交流； 对需求的变化具有较强的适应性； 支持软件复用。 2.3 面向对象工具——UML(Unified Modeling Language)统一建模语言 　　UML是对软件密集型系统中的制品(模型、源代码、测试用例等)进行可视化、详述、构造和文档化的语言。 （1）UML特点 统一的标准 面向对象 可视化、表示能力强大 独立于过程 概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用 （2）UML的构成 　　UML中的3类主要元素是基本构造块、规则、公共机制 （3）UML中的视图 　　UML中的视图包括用例视图、逻辑视图、实现视图、进程视图、部署视图，被称为“4+1”视图 用例视图：用于表达系统的功能性需求 逻辑视图：用于表示系统的概念设计和子系统结构等 实现视图：用于说明代码的结构 进程视图：用于说明系统中并发执行和同步的情况 部署视图：用于定义硬件结点的物理结构 2.4 面向对象分析(OOA

再上一篇中，介绍了生产者消费者模型[ https://blog.csdn.net/Misszhoudandan/article/details/80715426] 今天介绍读者写者模型（读多写少的场景） 写者负责再资源池中写 读者负责从资源池中读数据 同一时间内不允许多个写者进行写，但允许多个读者进行读 当写者和读者都准备占用资源池时，写者优先占用资源池（此问题描述的时写者优先级高的场景） 一个交易场所（资源池），此处用一个变量供读者和写者进行读写 两种角色，一组读者线程和一组写者线程 三种关系： .读者和写者之间为互斥关系，写者优先级高 .读者和读者之间为共享关系（没有互斥关系） .写者和写者之间为互斥关系 这里采用POXI线程库中的读写锁来实现 #include <stdio.h> #include <pthread.h> #include <unistd.h> //读者写者模型（读的频率高，写的频率低） //读者和读者之间关系为 共享 //写者和写者之间关系为 互斥 //读者和写者之间关系为 同步互斥关系 //读写锁 //读者加读锁（读者之间共享） //写者加写锁（写者之间互斥） //写者优先获取锁（写者优先级高） pthread_rwlock_t rw_lock ; //定义一个读写锁 //*******实现一个交易场所******************** int

在对linux 下的进程和线程的学习后，总结一下生产者消费者模型 生产者负责在生产池中进行生产 消费者负责消费生产池中的生产物 同一时刻生产池中只能有一个生产者/消费者 生产池中没有生产物时，消费者阻塞，直到生产者进行生产之后（生产池不未空），系统再唤醒消费者进行消费 生产池为满时，生产者阻塞，直到消费者进行消费之后（生产池未满），系统再唤醒生产者进行生产 一个交易场所（生产池），这里用一个带头结点的单向链表描述 两种角色，这里用若干个线程描述生产者，用若干个线程描述消费者 三种关系 ： 生产者与生产者之间为 互斥关系 ：消费者与消费者之间为 互斥关系 ：生产者与消费者之间为 同步与互斥关系 采用互斥量和条件变量 #include <stdio.h> #include <signal.h> #include <unistd.h> #include <pthread.h> #include <stdlib.h> //生产者消费者模型 //生产者和生产者之间为互斥关系 //消费者和消费者之间为互斥关系 //生产者和消费者之间为同步互斥关系 pthread_mutex_t mutex; //互斥量 pthread_mutex_t mutex_con; pthread_cond_t p_cond; int count= 0 ; //1.实现交易场所（带头结点，不带环的单向链表(栈结构)）

这篇文章讲的太好了，生怕以后被删掉。转到我博文列表里把-。- 正文： 开发者在刚开始尝试实现自己的微服务架构时往往会产生一系列问题 ： 微服务到底应该怎么划分？ 一个典型的微服务到底应该有多微？ 如果做了微服务设计，最后真的会有好处吗？ 回答上面的问题需要首先了解微服务设计的逻辑，科学的架构设计应该通过一些输入并逐步推导出结果，架构师要避免凭空设计和“拍脑门”的做法。 解耦的单体应用和微服务系统在逻辑上是一样的。对于服务拆分的逻辑来说，先设计高内聚低耦合的领域模型，再实现相应的分布式系统是一种比较合适的方式。 服务的划分有一些基本的方法和原则，通过这些方法能让微服务划分更有操作性。最终在微服务落地实施时也能按图索骥，无论是对遗留系统改造还是全新系统的架构都能游刃有余。 微服务拆分的几个阶段 在开始划分微服务之前，架构师需要在大脑中有一个重要的认识：微服务只是手段，不是目的。 微服务架构是为了让系统变得更容易拓展、更富有弹性。在把单体应用变成靠谱的微服务架构之前，单体系统的各个模块应该是合理、清晰地。 也就是说，从逻辑上单体系统和微服务没有区别，某种理想情况下微服务只是把单体系统的各个模块分开部署了而已（最近流行的monorepo把多个服务的代码仓库以模块的形式组织到了一起，证明了这一点）。 大量的实践教训告诉我们，混沌的微服务架构，比解耦良好的单体应用会带来更多麻烦。

一. 创建模型 表和表之间的关系 　　　　一对一、多对一、多对多　，用book表和publish表自己来想想关系，想想里面的操作，加外键约束和不加外键约束的区别，一对一的外键约束是在一对多的约束上加上唯一约束。 　　实例：我们来假定下面这些概念，字段和关系 　　作者模型：一个作者有姓名和年龄。 　　作者详细模型：把作者的详情放到详情表，包含生日，手机号，家庭住址等信息。作者详情模型和作者模型之间是一对一的关系（one-to-one） 　　出版商模型：出版商有名称，所在城市以及email。 　　书籍模型： 书籍有书名和出版日期，一本书可能会有多个作者，一个作者也可以写多本书，所以作者和书籍的关系就是多对多的关联关系(many-to-many);一本书只应该由一个出版商出版，所以出版商和书籍是一对多关联关系(one-to-many)。 　　模型建立如下： from django.db import models # Create your models here. class Author(models.Model): #比较常用的信息放到这个表里面 nid = models.AutoField(primary_key=True) name=models.CharField( max_length=32) age=models.IntegerField()　　 def __str__

使用EF Core的第一步是创建数据模型，模型建的好，下班走的早。EF Core本身已经设置了一系列约定来帮我们快速的创建模型，例如表名、主键字段等，毕竟约定大于配置嘛。如果你想改变默认值，很简单，EF Core提供了Fluent API或Data Annotations两种方式允许我们定制数据模型。 FluentAPI方式和Data Annotations方式，FluentAPI是通过代码语句配置的，Data Annotations是通过特性标注配置的，FluentAPI的方式更加灵活，实现的功能也更多。优先级为：FluentAPI>Data Annotations>Conventions。 数据标注方式比较简单，在类或字段上添加特性标注即可，对实体类型有一定的入侵。 FluentAPI方式通过在 OnModelCreating 方法中添加代码逻辑来完成，也可以通过实现 IEntityTypeConfiguration<T> 类来完成，方式灵活，更能更加强大。 OnModelCreating 方式： modelBuilder.Entity<Role>() .Property(m => m.RoleName) .IsRequired(); IEntityTypeConfiguration<T> 方式： 先定义 IEntityTypeConfiguration<T> 的实现：