求高手详细解释数据规划和数据库规划设计的区别，不要百度百科里那种模棱两可的答案，最好有自己见解的

我也说不明白，大概理解是这样：

数据存储过程-----数据逻辑------数据表----数据透视

大型的数据库是用Oracle来完成的，SQL中也包括这种做法，

1 按周期备份数据库，按数据逻辑备份数据库，按自动编号记录数据变更痕迹，这是第一层

2 用数据逻辑来建立数据表，如工厂的切割BOMB生产物料清单，银行的业主基本资料

3 数据表层是记录资料的

4 数据透视是分析数据的

数据表就象大树上的叶子，数据透视是树枝，逻辑是他的神经系统，存储过程是他的根。所以前期规划应该是搭建服务器，建立表存储过程规则和主表索引，子表索引，自动编号过程

第二个过程搜集基础资料，做物料清单、基础信息，进入数据调查阶段，规范层次逻辑

第三步就要建立数据表了，实施数据表建立和软件部署，发布软件

第四步进入测试阶段，建立数据透视，搜集资料重新按照实际应用制作客户端和服务器应用程序，搭建三层结构，并且建立数据权限，这一步最重要。

我是这么做的

通知是指源自于APP以用户为目标的信息片段，以下是通知的几个重要组成部分：

来源(Source)： 这是APP中生成通知的源头。每个APP根据自己不同的内容体系可以有多个内容池，信息在内容池中进行归类，这些内容池将会变成通知的来源。

信息(Information) ：以通知为载体传达给用户的消息。比如说“Jesse申请成为你的好友”或者“James赞了你的推文”。

类型(Type)： 通知主要分为两类——信息类和 *** 作类。如果你APP需要的话，这两种都可以继续区分子类别。

徽章(Badge) ：引导用户查看通知的视觉元素 。徽章里的指示可以是一个简单的点，也可以展示未读消息的计数。

锚点(Anchor) ：指的是界面中用来引导用户进入通知的提示位置。简单来说，锚点就是用户看到通知指引或徽章的地方。锚点并不一定只能打在通知的来源，也可以打在你希望体现有通知的地方。锚点可以用来展示多种来源的通知，当然也可以只展示一类。你可以这样想，来源是信息架构层面的概念，而锚点不过是你可以看到徽章的视觉元素。

通知是一种媒介，APP使用它与用户沟通，让用户有再次打开APP的可能性。因此通知是APP中十分重要的部分。让我来介绍几种常见的通知模型，并说明为什么它们适合于自己的APP。

在这个模型中，把所有的通知都放在了通知心中里。通知中心可以是一个精致的页面，也可以是一个d窗，这取决于你的界面设计。

无论通知的来源是什么，所有的通知都被锚点到通知中心里，然后再对通知进行导航分类。Medium就是使用这种模型，底部导航中的铃铛图标会出现徽章，从而作为指向所有通知的入口。视觉上区分已读和未读通知变得尤为重要，用户需要清晰地辨别这两类信息。

这种方式的最大优点在于灵活性，以一含百，即使未来有新的来源出现也可以应对。

设计原则：

通知中心式适合于：

这种方式中，所有的通知都被锚点到导航的菜单中，这些菜单也正是通知的来源。

APP中并没有一个共有的通知中心。看下WhatsApp的截图会更易理解，无论是安卓还是iOS版本，通知被锚点到了各自的来源——Chats和Calls。

这种方式的优点在于内容的易发现性，凭借通知用户可以非常直接地获取到信息，过程中无需进入额外的中间页。不过这种方式的灵活性和伸缩性不如通知中心式。

这种方式高度依靠APP本身的信息架构，导航本身必须可以容纳不同类别的通知。和上一个模型一样，这里也需要通过视觉设计来区分已读和未读通知。

设计原则：

来源锚点式适合于：

顾名思义是前两种模式的混合体，且使用最为广泛，Facebook、LinkedIn、 Twitter、Instagram等一些热门APP都在使用它。

例如：Facebook，消息中心变成了主导航中的一个菜单，用来展现哪些无法在主页面中展示锚点的通知。Facebook把好友邀请的通知锚点在了主导航的好友菜单中，而把推荐用户锚点到了通知中心。

Facebook目前已更新：

这种模型同时具备了前两种模型的优点并且可以适用于大部分情况。虽然你现在可以把所有通知都锚点到通知中心里，但仍有必要仔细考虑一下是不是有些场景的通知更应该优先使用来源锚点式。

设计原则：

混合式模型适用于：

上述的模型都要用在正确的环境中，根据你APP的信息架构来挑选适合的模型，可以帮助你提供想要的通知类型。

原文作者：Shashank Sahay

原文链接：>

MSG_ID 消息ID VARCHAR2(32 BYTE)

MSG_TITLE 消息 标题 VARCHAR2(100 BYTE)

MSG_CONTENT 消息内容 VARCHAR2(4000 BYTE)

CREATE_TIME 创建时间 DATE

MSG_TYPE 消息类别 VARCHAR2(50 BYTE)

MSG_FROM 消息来源 VARCHAR2(50 BYTE)

MSG_STATUS 消息状态 VARCHAR2(2 BYTE)

MSG_SENDER 消息发送者 VARCHAR2(50 BYTE)

MSG_SENDER_ID 发送者ID VARCHAR2(38 BYTE)

VERIFY_DATE 有效期限 DATE

MODIFY_TIME 修改时间 DATE

MODIFYER 修改人 VARCHAR2(50 BYTE)

SENDER_STATUS 发件人 状态 VARCHAR2(2 BYTE)

我的

很简单的一些关于消息通知的设计。

前端：

首先关于消息中心的入口，一般有两种做法，一种是作为一级页面展示（适用于消息通知重要级别高，如倚重消息页面的营销功能），一种是放置一个icon入口。 如下两图所示：

首先根据自己需要确定消息中心的入口展示，接下来我们看看消息中心页面展示：

其他几点细节：1、关于新消息提醒，通常使用圆点或数字角标，圆点对用户造成的压力更小，数字角标则对于用户点击更有吸引力。另外如果采用数字角标的话，数字上限是多少，超过上限了如何展示，这也是一个需要考虑的问题。

2、第一级页面消息内容展示多少字符，超过如何展示？ 常见展示字符在30-40个之间。（1个汉字为2个字符，1个数字或字母为1个字符）

下面是消息内容详情页面的几种展示：

关于消息格式需要后台设置，同时别忘了消息为空时的展示：

后台：

首先罗列需要的功能，主要有：1、新增消息  2、历史消息管理  3、用户群管理  4、 *** 作记录，下面依照这些功能便可以搭建出需要的后台框架：

前端展示的数据来源于后台，所以两者设计中一定要建立联系，相互对照，确保设计完善。

SQL Server 系统数据库在安装软件时自动创建，用于协助系统共同完成对数据库的 *** 作；也是数据库运行的基础；

1，master数据库

是SQL Server 2012的核心数据库，如果损坏则数据库软件无法运行，主要包含如下主要信息：

1）所有用户登陆名和用户ID所属角色

2）数据库存储路径

3）服务器中数据库的名称和相关信息

4）系统配置设置， SQL Server 初始化信息

2，model数据库

在创建数据库时，总是以一套预定义的标准为模板进行创建的。以model数据库为模板来创建其他数据库。且model数据库是tempdb数据库的基础。

3，tempdb数据库

它是一个临时数据库，用来存储用户建立的临时表和临时存储过程，存储用户定义的全局变量值。它存在于SQL Server会话期间，会话结束，则关闭tempdb数据库，且数据库丢失。

4，msdb数据库

用于代理计划警报和作业

SQL Server 数据库存储文件

数据库文件是由数据文件和事务日志文件组成。

1，数据库文件指数据库中用来存储数据库数据和数据库对象的文件，一个数据库只能由一个主数据库文件，扩展名为 mdf

2, 次数据库文件包含除主数据库文件外的所有数据文件，一个数据库可以没有次数据库文件，也可以由多个，扩展名为 ndf

3, 日志文件由一系列日志记录组成，它记录了存储数据库的更新情况等事务日志信息，用户对数据库进行的插入，删除，更新都会记录在日志文件中。数据库发生损坏时可根据日志文件分析出错原因，或者数据丢失时，使用事务日志恢复数据库。每个数据库至少要有一个日志文件。

SQL Server 数据库创建，使用T-SQL语言创建：

使用T-SQL语言删除数据库：

SQL Server 数据库迁移：

方法1：“分离/附加”数据库，即把数据库文件（MDF）和对应的日志文件（LDF）拷贝到其它磁盘上作备份，然后把这两个文件再拷贝到任何需要这个数据库的系统之中。

分离数据库就是将某个数据库从SQL Server数据库列表中删除，使其不再被SQL Server管理和使用，但该数据库的文件（MDF）和对应的日志文件（LDF）完好无损。分离成功后，就可以把该数据库文件（MDF）和对应的日志文件（LDF）拷贝到其它磁盘中作为备份保存。

分离之前，设置数据库为单个用户，并记住该数据库所在路径。

“任务”—“分离”

然后分离数据库页面选中“更新统计信息”复选框。若“消息”列中没有显示存在活动连接，则“状态”列显示为“就绪”；否则显示“未就绪”，此时必须勾选“删除连接”列的复选框。分离后资源管理器中数据库消失

将需要附加的数据库文件和日志文件拷贝到某个已经创建好的文件夹中。

右击数据库对象，并在快捷菜单中选择“附加”命令，打开“附加数据库”窗口。

添加—选择需要附件的数据库的MDF文件。“附件为”数据库名称可修改。

通知是指源自App内部，推送给用户的提示信息，一般包含标题和内容两部分，绝大部分通知均是文字内容。

来源(Source)： 这是APP中生成通知的源头。每个APP根据自己不同的内容体系可以有多个内容池，当系统、其他用户或者用户自己的 *** 作引起内容池变化时便会产生通知。

信息(Information) ：以通知为载体传达给用户的消息。比如说“Jesse申请成为你的好友”或者“James赞了你的推文”。

徽章(Badge) ：引导用户查看通知的视觉元素 。徽章里的指示可以是一个简单的点，也可以展示未读消息的数量。（对于强迫症患者来讲，徽章就是“恶魔”）

锚点(Anchor) ：指的是界面中用来引导用户进入通知的提示位置。简单来说，锚点就是用户看到通知指引或显示徽章的地方。锚点并不一定只能通知来源的地方显示，也可出现在你希望体现有通知的地方。锚点可以用来展示多种来源的通知，当然也可以只展示一类。你可以这样想，来源是信息架构层面的概念，而锚点不过是你可以看到徽章的视觉元素。

通知是App与用户沟通的一种方式，提高用户再次进入App的可能性，增加用户的粘性，同时也有几率唤醒那些沉默用户。因此通知是APP中十分重要的部分。常用的App通知模型主要有以下几种：

一、通知中心式

在这个模型中，将App内所有的通知都放在独立的通知心中里。通知中心可以是一个精致的页面，也可以是一个d窗，这可以根据需求及使用场景来确定。

无论通知的来源是什么，所有的通知都被锚点到通知中心里，然后再对通知进行导航分类。Medium就是使用这种模型，底部导航中的铃铛图标会出现徽章，从而作为指向所有通知的入口。视觉上区分已读和未读通知变得尤为重要，用户需要清晰地辨别这两类信息。

这种方式的优点在于比较灵活，扩展性较好，通知中心的入口可以根据需要进行调整，后续即便是增加了新的通知类型，只需在通知中心内部调整即可，对其他模块没有影响。

缺点就是众多类型的通知放在一起会略显杂乱，最好用tab加以区分

设计原则：

所有不同类别的通知都需要使用同一种设计模式，而且一定要考虑这种模式的扩展性。

如果你有太多通知来源，可能会出现界面乱糟糟的情况，这时候你就要考虑将同一类的通知合并成一个组，有助于减少信息重复出现。例如：James与2位好友开始关注你。

请确保通知中心的入口容易被发现和触达。

通知中心式适合于：

产品中的通知无法被锚点到任何一个已有的导航中。可能因为通知不和已有内容一致，或现有内容架构中并没有生成通知的来源。

有些来源的通知在已有页面中无法承载。

当时间很紧急，你可能很难把所有可能的通知场景该如何锚点都细想一遍。这种情况下，通知中心是一个很简单的方案，在实际 *** 作中也很灵活。

二、来源锚点式

这种方式中，所有的通知都被锚点到导航的菜单中，这些菜单也正是通知的来源。

APP中并没有一个共有的通知中心。看下WhatsApp的截图会更易理解，无论是安卓还是iOS版本，通知被锚点到了各自的来源——Chats和Calls。

这种方式的优点在于内容极易被发现，凭借通知用户可以非常直接地获取到信息，过程中无需进入额外的中间页。不过这种方式的灵活性和伸缩性不如通知中心式，一旦后续需要调整，可能各个消息来源模块都要改动，工作量会较大。

这种方式高度依靠APP本身的信息架构，导航本身必须可以容纳不同类别的通知，即所有的通知必须有与之对应的来源模块。和上一个模型一样，这里也需要通过视觉设计来区分已读和未读通知。

设计原则：

确保每一个通知可以和导航里的菜单对应起来。随着你APP复杂度的增加，各个通知的来源也随之变多，这个时候你可以考虑使用通知中心或者混合式的模型（把通知中心式和来源锚点式混合起来）。我们将在下一个段落中讲到混合式。

每一个锚点的设计模式应该可以承载各自的内容，并确保你的通知适合这种锚点的设计模式。用WhatsApp举例，锚点“聊天”本身有自己的设计模式定义了每一个聊天应该长成什么样，那关于聊天的通知就必须跟随这个设计模式。“电话”也是同理。

确保每一个锚点都易被发现与触达，尽量避免在子级页面中出现锚点。

来源锚点式适合于：

当所有的通知的来源可以被安置到APP首页（包含主导航）中。

你必须仔细想一遍所有需要通知的场景，且所有的通知可以被安置到现有的设计模型里。通知和来源的设计模式必须保持一致，这一点很重要。

三、混合模式

顾名思义是前两种模式的混合体，且使用最为广泛，Facebook、LinkedIn、 Twitter、Instagram等一些热门APP都在使用它。

例如：Facebook，消息中心变成了主导航中的一个菜单，用来展现哪些无法在主页面中展示锚点的通知。Facebook把好友邀请的通知锚点在了主导航的好友菜单中，而把推荐用户锚点到了通知中心。

这种模型同时具备了前两种模型的优点并且可以适用于大部分情况。虽然你现在可以把所有通知都锚点到通知中心里，但仍有必要仔细考虑一下是不是有些场景的通知更应该优先使用来源锚点式。

设计原则：

定义产品体系中所有的内容池，并按重要等级排序，这样可以帮助你列出哪些通知应该被锚点到来源，哪些可以直接进消息中心。由于这种模型与导航非常相关，通知的配置方式会影响到你导航的设计。

确保主锚点和通知中心易被发现，并且作为主页导航的一部分。

混合式模型适用于：

当你仔细考虑通知的场景后，发现一些通知可以被锚点到对应的来源中，但是有些却找不到已有的来源。

在你的导航体系中，有些来源藏得比较深。举个例子，Facebook导航中有个汉堡包餐单，当他的二级餐单中有通知来源时，汉堡包餐单就会变为锚点，例如：小组、视频、那年今天、收藏夹等。

结论

上述的模型都要用在正确的场景中，根据你APP的信息架构来选择合适的模型，可以让通知发挥更好的效果。

原文链接：>

以上就是关于求高手详细解释数据规划和数据库规划/设计的区别，不要百度百科里那种模棱两可的答案，最好有自己见解的全部的内容，包括:求高手详细解释数据规划和数据库规划/设计的区别，不要百度百科里那种模棱两可的答案，最好有自己见解的、APP的消息通知设计：你的APP适合什么样的通知模型、急求指点迷津，做一个java web工程局域网内的留言功能，给对方留言的数据库表该怎么设计呢等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！