说明：此版本的表结构基于github上的tag版本号——v5.4。以下内容是通过官网下载的项目还原及相关网络文章参考而来，也有部分是自己的理解。如有不当的地方，也欢迎大家指正。
表的具体说明
表名：AbpAuditLogs
作用：用于存储审计日志的相关信息
源码位置位于Abp.Zero.Common——Application——Auditing下，类名：AuditLog: Entity<long>, IMayHaveTenant。
实时记录访问服务，方法等等信息，结合日志功能，方便生产环境中的问题追踪。
表名：AbpBackgroundJobs
作用：记录用于持久化作业的后台作业信息
源码位置位于Abp——BackgroundJobs下，类名：BackgroundJobInfo: CreationAuditedEntity<long>。
在使用定时任务（如Quartz.net）的时候，可以把作业放在此表。可根据具体的框架扩展表字段。其中，优先级通过定义枚举实现的。如下图所示：
表名：AbpEditions
作用：记录应用程序的版本信息
源码位置位于Abp.Zero.Common——Application——Editions下，类名：Edition : FullAuditedEntity。
仅仅在类中定义了版本的唯一名称和版本的显示名称，唯一名称默认是GUID去掉‘-’的值（代码层面，非数据库中的）。其他字段通过实现接口等方式获取。创建后有一条种子数据。默认的显示名和唯一名都是Standard。
表名：AbpEntityChanges
作用：记录实体更改的相关信息
源码位置位于Abp——EntityHistory下，类名：EntityChange: Entity<long>, IMayHaveTenant。
后期补充的表（文末参考【1】中的文章里面没有此表）。和AbpEntityChangeSets是多对以关系，和AbpEntityPropertyChanges是一对多关系。暂时不清楚是出于什么目的设计的。
表名：AbpEntityChangeSets
作用：记录实体更改集合的相关信息
源码位置位于Abp——EntityHistory下，类名：EntityChangeSet: Entity<long>, IHasCreationTime, IMayHaveTenant, IExtendableObject。
后期补充的表（文末参考【1】中的文章里面没有此表）。关系同上。暂时不清楚是出于什么目的设计的。
表名：AbpEntityPropertyChanges
作用：记录实体属性更改的相关信息
源码位置位于Abp——EntityHistory下，类名：EntityPropertyChange: Entity<long>, IMayHaveTenant。
后期补充的表（文末参考【1】中的文章里面没有此表）。关系同上。暂时不清楚是出于什么目的设计的。
表名：AbpFeatures
作用：记录特征设置的基本信息（版本的）
源码位置位于Abp.Zero.Common——Application——Features下，类名：FeatureSetting: CreationAuditedEntity<long>, IMayHaveTenant。
仅仅在类中定义了特征名称和特征值，其他字段（除了EditionId和Discriminator）通过实现接口的方式获取。EditionId是外键，在其子类EditionFeatureSetting中添加的；Discriminator在生成映射（FeatureSettingMap类构造函数中）时添加的，用于鉴别子类？（FluentNHibernate.Mapping下有映射类定义）。对于中小系统，感觉这个表根本用不到。
表名：AbpLanguages
作用：记录应用程序的语言
源码位置位于Abp.Zero.Common——Localization下，类名：ApplicationLanguage: FullAuditedEntity, IMayHaveTenant。
此类是可序列化的。有初始化了种子数据，定义相关语言信息。此处定义的只是语言的基本信息，不是系统设置的显示语言。
表名：AbpLanguageTexts
作用：用于存储本地化文本的相关信息
源码位置位于Abp.Zero.Common——Localization下，类名：ApplicationLanguageText : AuditedEntity<long>, IMayHaveTenant。
此类是可序列化的。本地化的处理大多数都是通过定义xml文件的形式完成，但是也可将其数据保存到此表中完成。
表名：AbpNotifications
作用：用于存储通知请求，此通知是发给租户/用户的
源码位置位于Abp——Notifications下，类名：NotificationInfo : CreationAuditedEntity<Guid>。
此类是可序列化的。和下一个通知订阅表有点类似，只不过此表主要记录通知信息。通知类的几个表应该都是为SignalR而准备的。其中通知的严重性，或者说优先级是通过枚举定义的，如下图所示：
表名：AbpNotificationSubscriptions
作用：用于存储通知订阅的相关信息
源码位置位于Abp——Notifications下，类名：NotificationSubscriptionInfo : CreationAuditedEntity<Guid>, IMayHaveTenant。
和上面的通知表类似，只不过此表主要记录租户、用户订阅的通知。
表名：AbpOrganizationUnitRoles
作用：记录用户对组织单元的成员资格的相关信息
源码位置位于Abp.Zero.Common——Organizations下，类名：OrganizationUnitRole : CreationAuditedEntity<long>, IMayHaveTenant, ISoftDelete。
和下面的AbpOrganizationUnits表是多对一的关系。后期补充的表（文末参考中的文章里面没有此表）。和表AbpUserOrganizationUnits的作用类似，即此角色是否属于指定的单元组织，但是不知道为什么没有叫AbpRoleOrganizationUnits。（呵呵）
表名：AbpOrganizationUnits
作用：记录一个组织单元(OU)的相关信息
源码位置位于Abp.Zero.Common——Organizations下，类名：OrganizationUnit : FullAuditedEntity<long>, IMayHaveTenant。
和AbpOrganizationUnitRoles、AbpUserOrganizationUnits表是一对多关系。仅仅是组织机构的基本信息，不涉及业务逻辑。
表名：AbpPermissions
作用：记录用于授予/拒绝角色或用户的权限的相关信息
源码位置位于Abp.Zero.Common——Authorization下，类名：PermissionSetting : CreationAuditedEntity<long>, IMayHaveTenant。
记录用户、角色和租户的相关权限授予/拒绝信息，但是这个三个字段均可为空。授权默认为true（代码中的）。Abp框架默认给出了权限的保存（新增和修改）方法，检查权限一般使用特性的方式。其创建后就有默认的种子数据。
表名：AbpRoleClaims
作用：记录角色Claim的相关信息
源码位置位于Abp.Zero.Common——Authorization——Roles下，类名：RoleClaim : CreationAuditedEntity<long>, IMayHaveTenant。
后期补充的表（文末参考【1】中的文章里面没有此表），具体上不知道干嘛的。一般来讲，微软自带的身份认证里有这个（Claims）类似对象，但是在角色上，不知道要怎么用。
表名：AbpRoles
作用：记录角色的基本信息
源码位置位于Abp.Zero.Common——Authorization——Roles下，类名：AbpRoleBase : FullAuditedEntity<int>, IMayHaveTenant。
创建表时插入两条种子数据，一条和租户关联，否默认角色，另一条不和租户关联，但是是默认角色。如果标注为默认角色，系统会自动分配给新用户。Bool类型字段默认都是false。
表名：AbpSettings
作用：记录租户或用户的设置的相关信息
源码位置位于Abp.Zero.Common——Configuration下，类名：Setting : AuditedEntity<long>, IMayHaveTenant。
有默认种子数据。默认是添加电子邮件地址和收件人显示名称，还有一个默认语言——en。似乎关于用户和租户的设置，除了一些可以放在配置文件中，有些最后放在此表中，感觉上此表和AbpLanguageTexts表有点类似的作用。
表名：AbpTenantNotifications
作用：记录分发给相关租户的通知的相关信息
源码位置位于Abp——Notifications下，类名：TenantNotificationInfo : CreationAuditedEntity<Guid>, IMayHaveTenant。
和上面提到的通知表类似，此表关注的租户的。不知道此表的设计目的什么，感觉用AbpNotifications表即可，只是去掉了此表的用户相关字段。
表名：AbpTenants
作用：记录基本的租户信息
源码位置位于Abp.Zero.Common——MultiTenancy下，类名：AbpTenantBase : FullAuditedEntity<int>, IPassivable。
在生成前加入了AbpEditions表Id作为外键，默认生成一条种子数据，租户名称为Default。多租户支持（每个租户的数据自动隔离，业务模块开发者不需要在保存和查询数时写相应代码）。
表名：AbpUserAccounts
作用：记录摘要用户的相关信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：UserAccount : FullAuditedEntity<long>。
默认有两条种子数据。不知道这个表用作是什么。
表名：AbpUserClaims
作用：记录用户Claim的相关信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：UserClaim : CreationAuditedEntity<long>, IMayHaveTenant。
应该是使用微软自带的授权认证，记录其声明相关信息的。角色的那个类似表目标相似。
表名：AbpUserLoginAttempts
作用：用于保存用户的登录尝试的相关信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：UserLoginAttempt : Entity<long>, IHasCreationTime, IMayHaveTenant。
通过用户名，密码登录的用户信息，记录登录的结果等信息（不管是成功还是失败）。
表名：AbpUserLogins
作用：用于存储用于外部登录服务的用户登录的相关信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：UserLogin : Entity<long>, IMayHaveTenant。
默认没有数据，猜测是第三方登录的信息记录。
表名：AbpUserNotifications
作用：用于存储用户通知的相关信息
源码位置位于Abp——Notifications下，类名：UserNotificationInfo : Entity<Guid>, IHasCreationTime, IMayHaveTenant
默认没有数据。专注于用户通知的记录，其中包含了租户通知id字段，虽然源码中没有标识出是AbpTenantNotifications表的外键，但是猜测应该是的。另外，通知的状态由枚举定义，主要记录用户是否已经读取通知两种状态。如下图所示:
表名：AbpUserOrganizationUnits
作用：记录用户对组织单元(OU)的成员资格的相关信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：UserOrganizationUnit : CreationAuditedEntity<long>, IMayHaveTenant, ISoftDelete。
和AbpOrganizationUnits表是多对一的关系。即此用户是否属于指定的组织单元，或者在哪个部门（通俗的说）。
表名：AbpUserRoles
作用：记录用户和角色之间关系的信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：UserRole : CreationAuditedEntity<long>, IMayHaveTenant。
表名：AbpUsers
作用：记录用户的基本信息
源码位置位于Abp.Zero.Common——Authorization——Users下，类名：AbpUserBase : FullAuditedEntity<long>, IMayHaveTenant, IPassivable。
默认用户为admin，作为种子数据加入。删除了LastLoginTime字段（参考【1】）？主要是登录用户的信息，不怎么涉及业务用户的情况。其中说明了是多个表的外键。
表名：AbpUserTokens
作用：记录用户的身份验证令牌的相关信息
源码位置位于Abp.ZeroCore——Authorization——Users下，类名：UserToken : Entity<long>, IMayHaveTenant。
后期补充的表（文末参考【1】中的文章里面没有此表）。应该主要是api要用的，记录令牌的相关消息。
表名：AbpWebhookEvents
作用：记录存储创建的web挂钩的相关信息
源码位置位于Abp——Webhooks下，类名：WebhookEvent : Entity<Guid>, IMayHaveTenant, IHasCreationTime, IHasDeletionTime。
后期补充的表（文末参考【1】中的文章里面没有此表）。具体不知道作用是什么。
表名：AbpWebhookSendAttempts
作用：记录存储的webhook工作项的相关信息
源码位置位于Abp——Webhooks下，类名：WebhookSendAttempt : Entity<Guid>, IMayHaveTenant, IHasCreationTime, IHasModificationTime。
后期补充的表（文末参考【1】中的文章里面没有此表）。具体不知道作用是什么。其中对表AbpWebhookEvents的关联有明确的定义，但是对表AbpWebhookSubscriptions没有，猜测是WebhookSubscriptionId外键。
表名：AbpWebhookSubscriptions
作用：记录webhook的订阅信息
源码位置位于Abp——Webhooks下，类名：WebhookSubscriptionInfo : CreationAuditedEntity<Guid>, IPassivable。
后期补充的表（文末参考【1】中的文章里面没有此表）。具体不知道作用是什么。
关于外键的说明
大多数的表中都有租户id、用户id（其他少量出现的就不一一举例了），除了有的类中明确给出了是对应哪个表的外键的，其他都是没有明确说明的。如租户id，都是通过接口获取的。有明确说的，上面我都明确标出来了。对于没有明确指定的，个人觉得也可以把它们当成外键处理。只是可能没有在数据库中，或者代码中有相关的关联关系。
对时间定义的简单说明
DateTime字段类型对应的时间格式是 yyyy-MM-dd HH:mm:ss.fff ，3个f，精确到1毫秒(ms)，示例 2014-12-03 17:06:15.433 。
DateTime2字段类型对应的时间格式是 yyyy-MM-dd HH:mm:ss.fffffff ，7个f，精确到0.1微秒(μs)，示例 2014-12-03 17:23:19.2880929 。
如果用SQL的日期函数进行赋值，DateTime字段类型要用 GETDATE() ，DateTime2字段类型要用 SYSDATETIME() 。
参考
【1】http://www.mamicode.com/info-detail-2018026.html
【2】https://www.cnblogs.com/dudu/p/sql-server-datetime-vs-datetime2.html