精华内容
下载资源
问答
  • 五、数据库测试场景

    2019-09-27 14:47:17
    五、数据库测试场景 1.页面提交成功时检查数据是否正确地保存在数据库中 2.检查不接受空值的列值 3.数据应根据表设计被存储在单个或多个表中 4.索引名称应按照标准如IND_ <表名> _ < 列名> 5.表应该有...

    五、数据库测试场景

    1.页面提交成功时检查数据是否正确地保存在数据库中
    2.检查不接受空值的列值
    3.数据应根据表设计被存储在单个或多个表中
    4.索引名称应按照标准如IND_ <表名> _ < 列名>
    5.表应该有主键
    6.应对表中的列给出相应的描述信息(除了诸如创建时间、创建人等审计列)
    7.应该为每个数据库的添加/更新操作添加日志
    8.应该为需要的表创建索引
    9.检查是否只有操作完全成功后才将数据提交到数据库中
    10.一旦事务失败数据应该回滚
    11.数据库名称应按照应用程序类型命名,即测试,UAT,沙箱,现场(尽管这不是一个标准,但对数据库维护是很有帮助的)
    12.数据库逻辑名称应根据数据库名称命名(这不是标准但又有利于数据库维护)
    13.存储过程不应该以前缀“sp_”命名
    14.检查表审计列的值(如创建日期、创建人、更新日期、更新者、已删除、删除日期、删除者等等)填充正确
    15.检查输入数据保存时是否未被截断,在页面中显示的字段长度和数据库的字段长度应该是相同的
    16.检查包含最小、最大和浮点的数值字段
    17.检查数值字段含有负值(接受和拒绝两种情况)
    18.检查单选按钮和下拉列表正确地保存在数据库中
    19.检查数据库字段设计的数据类型和数据长度是否正确
    20.检查所有的表约束条件如主键、外键等是否正确实现
    21.测试存储过程和触发器的样本输入数据
    22.输入数据的首尾空格应在数据保存到数据库之前被自动隐去
    23.主键列不允许为NULL值

    展开全文
  • 转:redis数据库设计1

    2014-02-28 15:28:41
    本文来自@hoterran的个人博客运维与开发,作者列举了几种常用的应用场景,分别描述了其关系型数据库和Redis下的不同存储设计方法。值得参考。 丰富的数据结构使得redis的设计非常的有趣。不像关系型数据库那样,...

    浅谈Redis数据库的键值设计

    NoSQL带给我们的东西很多,高性能,水平扩展性,还有不一样的思维方式。本文来自@hoterran的个人博客运维与开发,作者列举了几种常用的应用场景,分别描述了其关系型数据库和Redis下的不同存储设计方法。值得参考。

    丰富的数据结构使得redis的设计非常的有趣。不像关系型数据库那样,DEV和DBA需要深度沟通,review每行sql语句,也不像memcached那样,不需要DBA的参与。redis的DBA需要熟悉数据结构,并能了解使用场景。

    下面举一些常见适合kv数据库的例子来谈谈键值的设计,并与关系型数据库做一个对比,发现关系型的不足之处。

    用户登录系统

    记录用户登录信息的一个系统, 我们简化业务后只留下一张表。

    关系型数据库的设计

    mysql> select * from login;
    +---------+----------------+-------------+---------------------+
    | user_id | name           | login_times | last_login_time     |
    +---------+----------------+-------------+---------------------+
    |       1 | ken thompson   |           5 | 2011-01-01 00:00:00 |
    |       2 | dennis ritchie |           1 | 2011-02-01 00:00:00 |
    |       3 | Joe Armstrong  |           2 | 2011-03-01 00:00:00 |
    +---------+----------------+-------------+---------------------+

    user_id表的主键,name表示用户名,login_times表示该用户的登录次数,每次用户登录后,login_times会自增,而last_login_time更新为当前时间。

    REDIS的设计

    关系型数据转化为KV数据库,我的方法如下:

    key 表名:主键值:列名

    value 列值

    一般使用冒号做分割符,这是不成文的规矩。比如在php-admin for redis系统里,就是默认以冒号分割,于是user:1 user:2等key会分成一组。于是以上的关系数据转化成kv数据后记录如下:

    Set login:1:login_times 5
    Set login:2:login_times 1
    Set login:3:login_times 2
    
    Set login:1:last_login_time 2011-1-1
    Set login:2:last_login_time 2011-2-1
    Set login:3:last_login_time 2011-3-1
    
    set login:1:name ”ken thompson“
    set login:2:name “dennis ritchie”
    set login:3:name ”Joe Armstrong“

    这样在已知主键的情况下,通过get、set就可以获得或者修改用户的登录次数和最后登录时间和姓名。

    一般用户是无法知道自己的id的,只知道自己的用户名,所以还必须有一个从name到id的映射关系,这里的设计与上面的有所不同。

    set "login:ken thompson:id"      1
    set "login:dennis ritchie:id"    2
    set "login: Joe Armstrong:id"    3

    这样每次用户登录的时候业务逻辑如下(python版),r是redis对象,name是已经获知的用户名。

    #获得用户的id
    uid = r.get("login:%s:id" % name)
    #自增用户的登录次数
    ret = r.incr("login:%s:login_times" % uid)
    #更新该用户的最后登录时间
    ret = r.set("login:%s:last_login_time" % uid, datetime.datetime.now())

    如果需求仅仅是已知id,更新或者获取某个用户的最后登录时间,登录次数,关系型和kv数据库无啥区别。一个通过btree pk,一个通过hash,效果都很好。

    假设有如下需求,查找最近登录的N个用户。开发人员看看,还是比较简单的,一个sql搞定。

    select * from login order by last_login_time desc limit N

    DBA了解需求后,考虑到以后表如果比较大,所以在last_login_time上建个索引。执行计划从索引leafblock 的最右边开始访问N条记录,再回表N次,效果很好。

    过了两天,又来一个需求,需要知道登录次数最多的人是谁。同样的关系型如何处理?DEV说简单

    select * from login order by login_times desc limit N

    DBA一看,又要在login_time上建立一个索引。有没有觉得有点问题呢,表上每个字段上都有素引。

    关系型数据库的数据存储的的不灵活是问题的源头,数据仅有一种储存方法,那就是按行排列的堆表。统一的数据结构意味着你必须使用索引来改变sql的访问路径来快速访问某个列的,而访问路径的增加又意味着你必须使用统计信息来辅助,于是一大堆的问题就出现了。

    没有索引,没有统计计划,没有执行计划,这就是kv数据库。

    redis里如何满足以上的需求呢? 对于求最新的N条数据的需求,链表的后进后出的特点非常适合。我们在上面的登录代码之后添加一段代码,维护一个登录的链表,控制他的长度,使得里面永远保存的是最近的N个登录用户。

    #把当前登录人添加到链表里
    ret = r.lpush("login:last_login_times", uid)
    #保持链表只有N位
    ret = redis.ltrim("login:last_login_times", 0, N-1)

    这样需要获得最新登录人的id,如下的代码即可

    last_login_list = r.lrange("login:last_login_times", 0, N-1)

    另外,求登录次数最多的人,对于排序,积分榜这类需求,sorted set非常的适合,我们把用户和登录次数统一存储在一个sorted set里。

    zadd login:login_times 5 1
    zadd login:login_times 1 2
    zadd login:login_times 2 3

    这样假如某个用户登录,额外维护一个sorted set,代码如此

    #对该用户的登录次数自增1
    ret = r.zincrby("login:login_times", 1, uid)

    那么如何获得登录次数最多的用户呢,逆序排列取的排名第N的用户即可

    ret = r.zrevrange("login:login_times", 0, N-1)

    可以看出,DEV需要添加2行代码,而DBA不需要考虑索引什么的。

    TAG系统

    tag在互联网应用里尤其多见,如果以传统的关系型数据库来设计有点不伦不类。我们以查找书的例子来看看redis在这方面的优势。

    关系型数据库的设计

    两张表,一张book的明细,一张tag表,表示每本的tag,一本书存在多个tag。

    mysql> select * from book;
    +------+-------------------------------+----------------+
    | id   | name                          | author         |
    +------+-------------------------------+----------------+
    |    1 | The Ruby Programming Language | Mark Pilgrim   |
    |    1 | Ruby on rail                  | David Flanagan |
    |    1 | Programming Erlang            | Joe Armstrong  |
    +------+-------------------------------+----------------+
    
    mysql> select * from tag;
    +---------+---------+
    | tagname | book_id |
    +---------+---------+
    | ruby    |       1 |
    | ruby    |       2 |
    | web     |       2 |
    | erlang  |       3 |
    +---------+---------+
    
    假如有如此需求,查找即是ruby又是web方面的书籍,如果以关系型数据库会怎么处理?
    select b.name, b.author  from tag t1, tag t2, book b
    where t1.tagname = 'web' and t2.tagname = 'ruby' and t1.book_id = t2.book_id and b.id = t1.book_id

    tag表自关联2次再与book关联,这个sql还是比较复杂的,如果要求即ruby,但不是web方面的书籍呢?

    关系型数据其实并不太适合这些集合操作。

    REDIS的设计

    首先book的数据肯定要存储的,和上面一样。

    set book:1:name    ”The Ruby Programming Language”
    Set book:2:name     ”Ruby on rail”
    Set book:3:name     ”Programming Erlang”
    
    set book:1:author    ”Mark Pilgrim”
    Set book:2:author     ”David Flanagan”
    Set book:3:author     ”Joe Armstrong”

    tag表我们使用集合来存储数据,因为集合擅长求交集、并集

    sadd tag:ruby 1
    sadd tag:ruby 2
    sadd tag:web 2
    sadd tag:erlang 3

    那么,即属于ruby又属于web的书?

    inter_list = redis.sinter("tag.web", "tag:ruby")

    即属于ruby,但不属于web的书?

    inter_list = redis.sdiff("tag.ruby", "tag:web")

    属于ruby和属于web的书的合集?

    inter_list = redis.sunion("tag.ruby", "tag:web")

    简单到不行阿。

    从以上2个例子可以看出在某些场景里,关系型数据库是不太适合的,你可能能够设计出满足需求的系统,但总是感觉的怪怪的,有种生搬硬套的感觉。

    尤其登录系统这个例子,频繁的为业务建立索引。放在一个复杂的系统里,ddl(创建索引)有可能改变执行计划。导致其它的sql采用不同的执行计划,业务复杂的老系统,这个问题是很难预估的,sql千奇百怪。要求DBA对这个系统里所有的sql都了解,这点太难了。这个问题在oracle里尤其严重,每个DBA估计都碰到过。对于MySQL这类系统,ddl又不方便(虽然现在有online ddl的方法)。碰到大表,DBA凌晨爬起来在业务低峰期操作,这事我没少干过。而这种需求放到redis里就很好处理,DBA仅仅对容量进行预估即可。

    未来的OLTP系统应该是kv和关系型的紧密结合。

    展开全文
  • 数据库测试场景

    2019-10-02 17:23:50
    数据应根据表设计被存储在单个或多个表中4.索引名称应按照标准如IND_ <表名> _ < 列名>5.表应该有主键6.应对表中的列给出相应的描述信息(除了诸如创建时间、创建人等审计列)7.应该为每个数据库的添加/...

    作为提醒

     

    1.页面提交成功时检查数据是否正确地保存在数据库中
    2.检查不接受空值的列值
    3.数据应根据表设计被存储在单个或多个表中
    4.索引名称应按照标准如IND_ <表名> _ < 列名>
    5.表应该有主键
    6.应对表中的列给出相应的描述信息(除了诸如创建时间、创建人等审计列)
    7.应该为每个数据库的添加/更新操作添加日志
    8.应该为需要的表创建索引
    9.检查是否只有操作完全成功后才将数据提交到数据库中
    10.一旦事务失败数据应该回滚
    11.数据库名称应按照应用程序类型命名,即测试,UAT,沙箱,现场(尽管这不是一个标准,但对数据库维护是很有帮助的)
    12.数据库逻辑名称应根据数据库名称命名(这不是标准但又有利于数据库维护)
    13.存储过程不应该以前缀“sp_”命名
    14.检查表审计列的值(如创建日期、创建人、更新日期、更新者、已删除、删除日期、删除者等等)填充正确
    15.检查输入数据保存时是否未被截断,在页面中显示的字段长度和数据库的字段长度应该是相同的
    16.检查包含最小、最大和浮点的数值字段
    17.检查数值字段含有负值(接受和拒绝两种情况)
    18.检查单选按钮和下拉列表正确地保存在数据库中
    19.检查数据库字段设计的数据类型和数据长度是否正确
    20.检查所有的表约束条件如主键、外键等是否正确实现
    21.测试存储过程和触发器的样本输入数据
    22.输入数据的首尾空格应在数据保存到数据库之前被自动隐去
    23.主键列不允许为NULL值
    ————————————————
    版权声明:本文为CSDN博主「Cy邀请函」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/weixin_45681608/article/details/101534979

    转载于:https://www.cnblogs.com/lqh-haodi/p/11598001.html

    展开全文
  • 1请你谈一谈在项目中数据库设计遇到的难点,并且你是怎么解决的? 1可以从范式的角度谈谈:关系模式一定要设计的合理,如果设计的不合理的话,会出现4个问题:1数据冗余太大,浪费大量的存储空间;2更新异常,数据...

    1请你谈一谈在项目中数据库设计遇到的难点,并且你是怎么解决的?

    1可以从范式的角度谈谈:关系模式一定要设计的合理,如果设计的不合理的话,会出现4个问题:1数据冗余太大,浪费大量的存储空间;2更新异常,数据冗余,更新数据时,维护数据完整性代价大;3插入异常,改插的数据插不进去;4删除异常,不该删除的数据不得不删。举个例子而言:一个描述学校的数据库,设计的对象:学生的学号(Sno) 所在系(Sdept) 系主任的名字(Mname) 课程名(Cname) 成绩(Grade)
    如果是设计成一个单一的关系模式U={Sno , Sdept ,Mname , Cname , Grade},这个关系模式,可能会出现一些部分函数依赖,传递函数依赖等等,可能这里我没有涉及,为了解决这个问题,我们一般是使用规范化数据库设计理论的知识来解决这个问题,数据库原理的有介绍过数据依赖的知识,我们接触的是使用函数依赖来解决这个问题,我们设计的关系模式一定要复符合我们的额BC范式的要求,即不能出现部分函数依赖,传递函数依赖,这样可以有效的解决一写不合理的函数依赖造成的不合理的数据库设计;

    2优化查询速度:我们考虑的一般是加索引的方式,通过一个主键索引;

    2在实际的开发中,你是如何使用线程池的?

    线程池的作用就是减少创建线程和回收线程的资源消耗,提高响应速度,方便管理;

    3谈谈Sleep和wait的区别

    1,所属的类不同:sleep方法是定义在Thread上 wait方法是定义在Object上
    2,对于锁资源的处理方式不同 sleep不会释放锁 wait会释放锁
    3,使用范围:sleep可以使用在任何代码块 wait必须在同步方法或同步代码块执行

    4 SpringMVC执行原理

    1 DispatcherServlet表示前置控制器,是整个SpringMVC的控制中心。用户发出请求,DispatcherServlet接收请求并拦截请求。
    2 DispatcherServlet自行调用HandlerMapping,HandlerMapping根据请求url查找Handler。
    3 HandlerExecution将解析后的信息传递给DispatcherServlet,如解析控制器映射等。
    4 HandlerAdapter表示处理器适配器,其按照特定的规则去执行Handler。
    5 Handler让具体的Controller执行。
    6 Controller将具体的执行信息返回给HandlerAdapter,如ModelAndView。
    7 HandlerAdapter将视图逻辑名或模型传递给DispatcherServlet。
    8 DispatcherServlet调用视图解析器(ViewResolver)来解析HandlerAdapter传递的逻辑视图名
    9 视图解析器将解析的逻辑视图名传给DispatcherServlet。
    10 DispatcherServlet根据视图解析器解析的视图结果,调用具体的视图。
    11 最终视图呈现给用户

    5Redis的基本数据类型?

    字符串(strings), 散列(hashes), 列表(lists), 集合(sets), 有序集合(sorted sets)

    6Redis各种基本数据类型的使用场景?

    1String

    存储内容:通常使用字符串,如果字符串以整数的形式展示,可以作为数字操作使用(但是仍是字符串)
    常用的命令:添加数据、修改数据 set key value 获取数据get key 删除数据 del key mset mget
    应用场景1:String类型作为数值时的增减;大型企业级应用中,分表操作是基本操作,使用多张表存储同类型数据,但是对应的主键id必须保证统一性,不能重复,MySQL数据库并不具有类似的机制,那么如何解决?设置数值数据增加指定范围的值,设置数值数据减少指定范围的值
    应用场景2:String 数据时效性设置;新闻网站会出现热点新闻,热点新闻最大的特征是对时效性,如何自动控制热点新闻的时效性;setex name 15 zs15s后过期;
    应用场景3:String类型之高热度数据访问加速;微博大V主页显示粉丝数与微博数量,这些数据就是热度数据,不断发生变化,这些数据如何放入Redis?在Redis中为大V用户设定用户信息,以用户主键和属性值作为key,后台设定时间定时刷新即可:user: id :5765898790:focuss:3050

    2Hash

    127.0.0.1:6379> Hset people name zs age 21
    (integer) 2
    127.0.0.1:6379> Hget people name
    "zs"
    127.0.0.1:6379> Hget people age
    "21"
    127.0.0.1:6379> Hmget people name age
    1) "zs"
    2) "21"
    127.0.0.1:6379> Hgetall people
    1) "name"
    2) "zs"
    3) "age"
    4) "21"
    127.0.0.1:6379> Hdel people name
    (integer) 1
    127.0.0.1:6379> Hgetall people
    1) "age"
    2) "21"
    

    应用场景1:hash类型应用场景购物车:电商网站购物车的设计与实现;
    在这里插入图片描述
    以用户的ID作为Key,每位用户创建一个hash存储结构存储对象的购物车信息,商品的编号作为field,购买的数量作为value进行存储。添加商品的时候,添加filed vale即可;浏览:遍历hash即可;删除商品:删除field即可;

    3List

    在redis里面,我们可以把list玩成栈,队列

    lpush key value1 [value2] …
    rpush key value1 [value2] …
    
    lrange key start stop //获取从左数第start到stop个元素,从0开始
    lindex key index //查询第i个元素
    llen key //list的长度
    
    lpop key //获取并删除左边第一个元素
    rpop key //获取并删除右边第一个元素
    

    业务场景1:微信朋友圈点赞,要求按照点赞顺序显示点赞好友信息。如果取消点赞,移除对应好友信息。
    在这里插入图片描述
    业务场景2:最新消息的展示:新闻、资讯类网站如何将最新的新闻或资讯按照发生的事件顺序展示

    4Set

    添加数据
    sadd key menber1 [member2]
    获取全部数据
    smembers key
    删除数据
    srem key member1 [member2]
    获取集合数据总量
    scard key
    判断集合中是否包含指定数据
    sismember key member
    

    业务场景1:随机操作数据;每位用户首次使用进入头条时候会设置3项爱好的内容,但是后期为了增加用户的活跃度,兴趣点,必须让用户对其他信息类别逐渐产生兴趣,增加客户留存度,如何实现?1系统分析出各个分类的最新或最热点信息条目并组织成set集合;2随机挑选其中部分信息;3配合用户关注信息分类中的热点信息组织展示的全信息集合

    业务场景2:业务场景-共同好友:

    求两个集合的交、并、差集并存储到指定集合中
    sinterstore destination key1 [key2]
    sunionstore destination key1 [key2]
    sdiffstore destination key1 [key2]
    

    业务场景3:访问量统计去重:针对不同的统计类型有不同的数据存储方式:1利用set集合的数据去重特征,记录各种访问数据;2建立string类型数据,利用incr统计日访问量(PV);3建立set模型,记录不同cookie数量(UV);4建立set模型,记录不用IP数量(IP)

    5sorted sets

    业务场景1:建立排序依据:票选广东十大杰出青年,各类综艺选秀海选投票,聊天室活跃度统计,游戏好友亲密度;

    zadd key score value # 添加值,score代表优先级,可以一次添加多个
    
    zrange key start end # 获取start-end的值,0 -1代表获取所有值
    
    # 排序如何实现
    zrangebyscore key startscore endscore # 对集合通过score排序, 默认升序
    
    zrangebyscore key -inf inf withscores # 显示score
    
    zrevrange salary 0 -1 [withscores] # 降序排列所有值
    
    zrem key member [member] # 移除元素
    
    zcard key # 获取有序集合中的个数
    
    zcount key start end # 获取start-end之间的个数
    
    

    7JVM堆大小的是如何设计的?

    -Xmx:最大堆大小
    -Xms:初始堆大小
    -Xmn: 年轻代大小

    Java整个堆大小设置,Xmx 和 Xms设置为老年代存活对象的3-4倍
    永久代 PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍
    年轻代Xmn的设置为老年代存活对象的1-1.5倍
    老年代的内存大小设置为老年代存活对象的2-3倍

    Sun官方建议年轻代的大小为整个堆的3/8左右

    8各种垃圾回收器使用的垃圾回收算法?

    在这里插入图片描述

    9为什么CMS不使用标记压缩算法,G1使用的标记压缩算法呢?

    在并发清理的过程中,用Compact整理内存的时候,原来用户线程使用的内存就不可以使用了,要保证用后线程的继续运行,前提是它运行的资源不受影响。MarkCompact 更加适合STW的场景下。

    G1的回收是以region为单位,region之间可以看做是复制算法,但整体实际上可以看做是标记压缩算法,这种算法可以避免内存碎片,这种特性有利于程序的长时间运行,分配大对象时不会因为无法找到连续的内存 而提前触发下一次GC.尤其是堆很大的时候。

    10JVM的内存模型?

    在这里插入图片描述
    JVM包含两个子系统和两个组件,两个子系统为Class loader(类装载)、Execution engine(执行引擎);两个组件为Runtime data area(运行时数据区)、Native Interface(本地接口)

    Class loader(类装载):根据给定的全限定名类名(如:java.lang.Object)来装载class文件到Runtime data area中的method area。

    Execution engine(执行引擎):执行classes中的指令。

    Native Interface(本地接口):与native libraries交互,是其它编程语言交互的接口。

    Runtime data area(运行时数据区域):这就是我们常说的JVM的内存。

    作用 :首先通过编译器把 Java 代码转换成字节码类加载器(ClassLoader)再把字节码加载到内存中,将其放在运行时数据区(Runtime data area)的方法区内,而字节码文件只是 JVM 的一套指令集规范,并不能直接交给底层操作系统去执行,因此需要特定的命令解析器执行引擎(Execution Engine),将字节码翻译成底层系统指令,再交由 CPU 去执行,而这个过程中需要调用其他语言的本地库接口(Native Interface)来实现整个程序的功能。

    程序计数器(Program Counter Register)当前线程所执行的字节码的行号指示器,字节码解析器的工作是通过改变这个计数器的值,来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能,都需要依赖这个计数器来完成;

    Java 虚拟机栈(Java Virtual Machine Stacks):用于存储局部变量表、操作数栈、动态链接、方法出口等信息;

    本地方法栈(Native Method Stack):与虚拟机栈的作用是一样的,只不过虚拟机栈是服务 Java 方法的,而本地方法栈是为虚拟机调用 Native 方法服务的

    Java 堆(Java Heap):Java 虚拟机中内存最大的一块,是被所有线程共享的,几乎所有的对象实例都在这里分配内存;

    方法区(Methed Area):用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。

    展开全文
  • 基于MySQL 数据库的审计设计方案

    千次阅读 2018-01-18 17:23:42
    场景描述 3 使用范围规则 4 角色与职责 5 审计系统环境的部署 5.1 MySQL数据库部署 5.2 Replicate 部署 5.3 半同步复制配置 5.4 备份策略  6 审计操作 6.1数据库层面审计操作
  • 外键是否采用看业务应用场景,以及开发成本的,大致列下什么时候适合,什么时候不适合使用: 1. 互联网行业应用不推荐使用外键: 用户量大,并发度高,为此数据库服务器很容易...综合上述2句话描述,也即数据库服务
  • 本文来自@hoterran的个人博客运维与开发,作者列举了几种常用的应用场景,分别描述了其关系型数据库和Redis下的不同存储设计方法。值得参考。 丰富的数据结构使得redis的设计非常的有趣。不像关系型数据库...
  • 用户收藏信息的表结构设计 收藏记录表:维护用户和收藏信息之间的关系 字段名数据类型长度主键描述 id varchar 36 Yes UUID user_id varchar 32 No 用户Id resource_id bigint ...
  • 在我们实际的应用环境中,这个问题是绝对会面对的,当然我也不例外,举几个例子描述一下问题场景。 1、电商项目常遇到的商品信息,用户购买了一个商品,完成一次购物体验,这个时间,我们涉及到几个环节,选择商品...
  • redis作为一款高性能key-value数据库,还拥有持久化,多种数据结构,数据备份(主从)等优势,我们本篇先说结构和常用命令和使用场景 基础部分 1.string类型 string主要用于记录字符串结构的缓存数据,常用于存储...
  • 在我们实际的应用环境中,这个问题是绝对会面对的,当然我也不例外,举几个例子描述一下问题场景。1、电商项目常遇到的商品信息,用户购买了一个商品,完成一次购物体验,这个时间,我们涉及到几个环节,选择商品、...
  • 您已经给出了设计的某些方面,但没有给出它代表/实现/描述的业务“场景”或者它是如何实现的.SQL NULL,UNIQUE,PKs& FK是各种约束.约束是对可以出现的数据库值的限制. SQL FK表示表中列列表的子行值必须出现在列表...
  • 数据库的简单建模

    多人点赞 热门讨论 2020-05-16 22:29:04
    其中的难点在于如何使用数据表以及表间关系来描述出相应的功能场景,能够应对以后的各种查询需要,这对刚接触数据库的使用者来说是有些困难的,但是只要认真思考,按照步骤来操作相信最后的结果不会差。
  • 数据库加锁

    2018-03-14 09:53:06
    在这个场景中,由于是公司的业务后台系统,主要是用于审核人员的审核工作,并发量并不是很高,而且任务的分配规则设计成了通过审核人员每次主动的请求拉取,然后服务端从任务池中随机的选取任务进行分配。这个场景...
  • 数据库架构简要解析

    2019-08-02 17:32:02
    1. 场景描述 Greenplum用了大半年了,要给部门其他同事做下分享,写了个ppt,其中看到“ Greenplum是一款典型的Shared-Nothing 分布式数据库系统。”,看到Shared-Nothing架构,以前只从字面上知道就是不共享,但是...
  • 我们在平常开发过程中,在设计数据的时候,经常碰到数据类型选择的问题,为了更快,更合适地选择正确的数据类型,所以在这里做个总结。 分类 sql server 数据类型 c# 数据类型 描述 应用场景 字符和字符串 char(n...
  • 云计算基础与应用 第六章 数据库

    千次阅读 2020-06-28 20:03:41
    文章目录6.1 数据库概述6.2 数据库分类6.3 数据库设计6.5 云数据库运用场景和实例 6.1 数据库概述 数据库,数据库是指长期存储在计算机内的,有组织可共享的数据的集合。 数据库中的数据按一定的数学模型组织...
  • 故障描述 自上个月某个功能改动上线以后,最近生产上连环出现了多个生产故障,故障基本描述如下: error日志出现数据库连接异常,而实际交易量似乎并没有...场景描述 在详细说明上述故障之前,需要简单描述一...
  • 一般地,在进行数据库设计时,应遵循三大原则,也就是我们通常说的三大范式,即第一范式要求确保表中每列的原子性,也就是不可拆分;第二范式要求确保表中每列与主键相关,而不能只与主键的某部分相关(主要针对联合...
  • 在一个复杂的系统里面,为了动态生成数据表单和字段自定义,很多方式都是自定义设计,如果项目不够成熟很有可能会遇到如下所描述的情况,比如并发场景下一个用户唯一自增ID出现重复,业务数据同时涉及到A、B、C、D...
  • ORACLE数据库Maximum Availability技术架构 目录 1高可用场景架构讨论 2RAC高可用最佳实践 3双活高可用最佳实践 架构篇高可用讨论 什么是高可用 高可用性High Availability通常来描述一个系统经过专门的设计从而 ...
  • 我有三个表:积分明细表 ...并且可以追加积分我的问题是数据库表应该如何设计:方案一:A表和C表存储该条记录获取的积分数,同时在P表也存一笔积分记录,描述用文字注明,不与A表C表相关联问题:1,实际业务场景不仅...
  • 该篇文章从关系型数据库和非关系型数据库来讲述,牵扯到设计、索引、隔离级别以及... 对于数据库设计来说,不仅仅要考虑范式要求,为了节省查询效率,允许适当的有一些冗余字段。 关系型数据库 关系型数据是面向对
  • E-R模型即实体-关系模型,E-R模型就是描述数据库存储数据的结构模型。 使用场景 对于大型公司开发项目,我们需要根据产品经理的设计,我们先使用建模工具, 如:power designer,db desinger等这些软件来画出实体-...
  • 技术创新变革未来ORACLE数据库Maximum Availability技术架构目录1高可用场景架构讨论2RAC高可用最佳实践3双活高可用最佳实践架构篇高可用讨论什么是高可用 高可用性High Availability通常来描述一个系统经过专门的...
  • 框架的API设计直接面向数据库操作,不绕弯子,开发者只需要数据库基本知识,不必学习大量新的操作概念即可使用API完成各种DDL/DML操作。 最大限度利用编译器减少编码错误的可能性 API设计和元数据模型(meta-model...

空空如也

空空如也

1 2 3 4 5 ... 17
收藏数 340
精华内容 136
关键字:

数据库设计场景描述