sqlserver

Session模型简介 在学习之前我们会疑惑，Session是什么呢？简单来说就是服务器给客户端的一个编号。当一台WWW服务器运行时，可能有若干个用户浏览正在运正在这台服务器上的网站。当每 个用户首次与这台WWW服务器建立连接时，他就与这个服务器建立了一个Session，同时服务器会自动为其分配一个SessionID，用以标识这个用 户的唯一身份。这个SessionID是由WWW服务器随机产生的一个由24个字符组成的字符串，我们会在下面的实验中见到它的实际样子。 　　这个唯一的SessionID是有很大的实际意义的。当一个用户提交了表单时，浏览器会将用户的SessionID自动附加在HTTP头信息 中，（这是浏览器的自动功能，用户不会察觉到），当服务器处理完这个表单后，将结果返回给SessionID所对应的用户。试想，如果没有 SessionID，当有两个用户同时进行注册时，服务器怎样才能知道到底是哪个用户提交了哪个表单呢。当然，SessionID还有很多其他的作用，我们会在后面提及到。 　　除了SessionID，在每个Session中还包含很多其他信息。但是对于编写ASP或ASP.NET的程序与来说，最有用的还是可以通过 访问ASP/ASP.NET的内置Session对象，为每个用户存储各自的信息。例如我们想了解一下访问我们网站的用户浏览了几个页面

微服务确实是行业的一个趋势，我自己也在把一些项目往微服务架构迁移。玩微服务架构配置中心是一个绕不过去的东西，有很多大牌的可以选，比如spring-cloud-config，apoll，disconf等等。而我为什么还要造一个轮子呢？一来这些都不是.net实现的，我就想试试用.net core实现一个，而且他们也对.net不太友好，也只有apoll提供了官方的.net客户端。二来这些组件都太重量级了，比如apoll，光跑起来就要部署多个节点（admin,portal,meta sevice）还要依赖eureka。很多旧的项目往微服务迁移的时候并不是一下次全部调整完成的，可能是一步步来的，比如先把所有的服务都容器化，并没有使用微服务全家桶。而且有的项目也不需要微服务全家桶，毕竟微服务不是银弹，很多项目单体结构就足够了，有些项目传统的SOA架构也可以了。（唠叨一句，那种毫无流量毫无并发的项目，几人几天就搞完的强上微服务真的好吗？）但是这些项目也可能是分布式的，容器化部署的，那么这些项目我觉得也是需要配置中心的，因为在分布式、容器化环境下更改配置实在是太麻烦了。可以说配置中心并不是微服务独有的。基于以上原因我提炼了一些配置中心必备的功能，做的尽量简单（陋），开发了AgileConfig，为.net core的生态尽一份绵薄之力。 Github求star： AgileConfig

在我们开发各种应用的时候，都会碰到很多不同的问题，这些问题涉及架构、模块组合、界面处理、共同部分抽象等方面，我们这里以Winform开发为例，从系统模块化、界面组件选择、业务模块场景划分、界面基类和辅助类处理、代码生成工具辅助开发等方面介绍在实际项目开发过程中碰到的困境和相关的解决方案，以便分析其中是如何逐步提高效率和整体用户体验的。 1、系统模块化 软件和建筑工程很类似，都是需要构建一个庞大而功能完整的一个系统，而工程化也意味着需要多人协作，那么就需要把一个庞大的系统横向或者纵向划分为各个可以独立施工完成的模块，虽然各个模块之间有所衔接或者交互，但是基本上可以以模块化的方式来构建，这个也是工程化开发的精髓所在。 以一个软件管理系统为例，我们尽可能把精力焦点放在客户的业务需求上，而对于常规的如权限控制、字典管理等一些常用的内容，由于它们的处理逻辑在特定领域上基本上比较固定一些，可以尽可能独立并重复使用， 而有时候，以某个特定的业务来说，同时很多处理规则也是不变的，因此也可以以业务模块的方式来划分，从而类似通用模块的方式重复使用。 模块化类似小孩子搭积木的方式构建一个所要的形状，虽然软件和建筑在这方面肯定更加复杂化，但是模块化系统是大势所趋，也是简化开发、易于维护、提高系统健壮性的重要举措。 2、界面组件选择 在Winform内置的传统样式里面，虽然提供了很多很好的界面组件

在我们开发各种应用的时候，都会碰到很多不同的问题，这些问题涉及架构、模块组合、界面处理、共同部分抽象等方面，我们这里以Winform开发为例，从系统模块化、界面组件选择、业务模块场景划分、界面基类和辅助类处理、代码生成工具辅助开发等方面介绍在实际项目开发过程中碰到的困境和相关的解决方案，以便分析其中是如何逐步提高效率和整体用户体验的。 1、系统模块化 软件和建筑工程很类似，都是需要构建一个庞大而功能完整的一个系统，而工程化也意味着需要多人协作，那么就需要把一个庞大的系统横向或者纵向划分为各个可以独立施工完成的模块，虽然各个模块之间有所衔接或者交互，但是基本上可以以模块化的方式来构建，这个也是工程化开发的精髓所在。 以一个软件管理系统为例，我们尽可能把精力焦点放在客户的业务需求上，而对于常规的如权限控制、字典管理等一些常用的内容，由于它们的处理逻辑在特定领域上基本上比较固定一些，可以尽可能独立并重复使用， 而有时候，以某个特定的业务来说，同时很多处理规则也是不变的，因此也可以以业务模块的方式来划分，从而类似通用模块的方式重复使用。 模块化类似小孩子搭积木的方式构建一个所要的形状，虽然软件和建筑在这方面肯定更加复杂化，但是模块化系统是大势所趋，也是简化开发、易于维护、提高系统健壮性的重要举措。 2、界面组件选择 在Winform内置的传统样式里面，虽然提供了很多很好的界面组件

spring 框架的xml文件如何读取properties文件数据 第一步：在spring配置文件中 注意：value可以多配置几个properties文件 <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <list> <value>/db.properties</value> </list> </property> </bean> 第二步： 在src目录下面建立db.properties文件 user=sa password=sa driver=com.microsoft.sqlserver.jdbc.SQLServerDriver url=jdbc:sqlserver://localhost:1433;databaseName=DB1 第三步： 在spring的配置文件中通过EL表达式的形式调用 ${user} <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3

微服务确实是行业的一个趋势，我自己也在把一些项目往微服务架构迁移。玩微服务架构配置中心是一个绕不过去的东西，有很多大牌的可以选，比如spring-cloud-config，apoll，disconf等等。而我为什么还要造一个轮子呢？一来这些都不是.net实现的，我就想试试用.net core实现一个，而且他们也对.net不太友好，也只有apoll提供了官方的.net客户端。二来这些组件都太重量级了，比如apoll，光跑起来就要部署多个节点（admin,portal,meta sevice）还要依赖eureka。很多旧的项目往微服务迁移的时候并不是一下次全部调整完成的，可能是一步步来的，比如先把所有的服务都容器化，并没有使用微服务全家桶。而且有的项目也不需要微服务全家桶，毕竟微服务不是银弹，很多项目单体结构就足够了，有些项目传统的SOA架构也可以了。（唠叨一句，那种毫无流量毫无并发的项目，几人几天就搞完的强上微服务真的好吗？）但是这些项目也可能是分布式的，容器化部署的，那么这些项目我觉得也是需要配置中心的，因为在分布式、容器化环境下更改配置实在是太麻烦了。可以说配置中心并不是微服务独有的。基于以上原因我提炼了一些配置中心必备的功能，做的尽量简单（陋），开发了AgileConfig，为.net core的生态尽一份绵薄之力。 Github求star： AgileConfig

需求是需要用python往 SqlServer中的image类型字段中插入二进制图片 核心代码，研究好几个小时的代码： 安装pywin32，adodbapi 安装pywin32，adodbapi image_url = " 图片链接 " try : image_result = session.get(url=image_url, headers=headers, stream= True) except : image_result = session.get(url=image_url, headers=headers, stream= True) local_filename = md5(image_url) + " .png " print " 图片下载成功 " with open(local_filename, ' wb ' ) as f: for chunk in image_result.iter_content(chunk_size=1024 ): if chunk: # filter out keep-alive new chunks f.write(chunk) f.flush() f.close() # 读取图片，二进制格式，注意是rb f1 = open(local_filename, " rb " , ) b = f1.read() f1.close()

目录 第3章：关系数据库标准语言 SQL 3.1、SQL概述 3.1.1、历史 3.3.2、SQL语言的功能 3.3.3、SQL的特点 3.3.4、基本概念 3.2、学生-课程数据库 3.3、数据定义 3.3.1、使用数据库 3.3.2、SQLServer中的数据类型 3.3.3、基本表的建立（create） 3.3.4、基本表的修改（add、alter、drop） 3.3.5、基本表的删除（drop） 3.3.6、索引的建立和删除 3.4、数据查询 3.4.1、单表查询 3.4.2、集合查询 3.4.3、连接查询 3.4.4、嵌套查询 3.5、数据更新 3.5.1、插入数据（insert） 3.5.2、修改数据（update） 3.5.3、删除数据（delete） 3.6、视图 3.6.1、视图概述 3.6.2、定义视图 3.6.3、查询视图 3.6.4、更新视图 3.6.5、视图的作用 第3章：关系数据库标准语言 SQL 基于SQLServer学习使用，与MySQL有略微差别！ 3.1、SQL概述 3.1.1、历史 1974年，由Boyce和Chamber提出。 1975-1979年，在由IBM的San Jose研究室研制的System R上实现，称为Sequel，现在称为SQL (Struceured Query Languang)。 1986年10月，美国国家标准局

CAP源码追踪（一）消息是如何执行的，执行后又是如何执行回调的 场景 .NET Core 3.1 nuget包：DotNetCore.CAP.RabbitMQ 3.0.2 前言 以对话为引，梳理我们的问题: 小明-聪明绝顶的程序猿，小红-绝美程序媛 小红:小明，在CAP中，我们通过 CapSubscribe 特性来订阅方法，而我们写的消息处理中，返回值一般都是void/Task，那么这个返回值类型有什么用呀或者说这个返回值有什么用呢？ 小明一看表现的机会来了，马上回复了一句：百因必有果，既然有返回类型这个东西，那么CAP设计者肯定会利用这一点来进行应用，不会无故忽视这个功能的 小红：小明，那它到底有什么作用呢？ 小明：既然想知道它的作用，那么就应该去学习它的消息执行原理，分析其执行过程，自然就明白它的返回值的作用了。 小红：哇，问题一下从返回值的作用上升到了CAP执行原理了，小明，快给我讲讲呀😉 小明心想是时候表演真正的技术了~✨ @# *$&( #@*&(^$#@( 正文 从应用层面来看，我们使用CAP主要就是使用它的消息发送和订阅，既然要学习它的执行原理，那么就直接从消息发送出发来学习 MQ发送 以常用情况为例，我们通过注册的 ICapPublisher 下的 PublishAsync 来发送消息 首先先看一下方法定义： Task PublishAsync<T>(string

一、选择SQL Server升级方法 升级SQL Server的方法归结为几个业务目标：最短的停机时间、最少的花费、最小的风险。 这几个目标通常是无法兼具的，以下每种方法都有利弊，因此根据业务情况选择正确的升级方法非常重要。 1. 业界最常用的升级或迁移SQL Server方法 全备还原 附加和分离 就地升级 大型数据库的差异还原 使用日志传送升级SQL Server 滚动升级（停机时间最短） 2. SQL Server升级 vs 迁移 首先区别一下SQL Server中的迁移和升级术语，有时这些术语会被互换使用，但它们确实有一些不同之处。 1) 升级SQL Server意味着 只升级Edition，例如从SQL Server 2014标准版（SE）升级到SQL Server 2014企业版（EE）。 只升级Version，例如从SQL Server 2012（EE）升级到SQL Server 2016（EE）。 升级Edition和Version。例如从SQL Server 2012（SE）升级到SQL Server 2017（EE）。 Service Pack（SP）和累积更新（CU）的安装相当于小版本升级。 2) 迁移可能包括也可能不包括SQL Server的升级，但这意味着将数据库从一个实例移动到另一个实例。 例如更换SQL Server的物理机或操作系统 例如一个SQL