标签: schema

我对 MySQL 数据库模式对于火车时刻表的外观感兴趣。

通常，这以表格形式呈现为最终结果。

Train No.    11111  22222  11111
Train Day    Mo-Fr  Sat    Sun
Station A  d 06.00  07.00  07.00
Station B  d 06.10         07.10
Station C  d 06.20  07.15   
Station D  a 06.30         07.40
Station D  d 06.35  07.25
Station E  d 06.45  07.45

所以每列火车都有一个火车编号，但这不是唯一的，因为该编号将在周一至周五到周六和周日重复。然后一列火车会停在多个车站，但不是所有车站，有时车站需要到达 (a) 和出发 (d) 时间，或其中之一。

车站可以按距离排序。

到目前为止，我认为我需要表格：

• 车站（ID、名称、距离、线路）
• 火车（ID、火车编号、日间运营、详细信息）
• 火车运行（Train.ID、Station.ID、arr/dep、time、notes）

这是否足够规范化？

• 应该说周一至周五的火车 11111 只是一个包含大量日间操作组合的条目，即 7 列（M、T、W、Th、F、S、Su）？
• 难道它不也应该处理只在一个日期运行并且每周不重复的一次性火车吗？

我正在构建一个站点（“站点”），并且正在考虑如何为其设计数据库架构。

我有一些会影响结果的场景：

• 用户可以选择在本站注册一个本地账号，这将使他日后使用该账号登录自己的本站账号。
• 用户可以选择通过另一个站点（“外部站点”）（例如 facebook connect、google、foursquare 等）登录，这将使他将来可以使用该站点登录他在该站点上的帐户。
• 他选择哪种登录方法（本地帐户或外部站点帐户）并不重要，用户将能够使用外部站点（例如 facebook、twitter、instagram 等）在站点上验证他的帐户以供使用他在外部站点上的数据（例如他在 twitter 上的推文，他在 flickr 上的照片等），在站点中。

我应该如何设计数据库的架构？

对于前两个场景，我想有一个名为的表Users，它有一个id, 和一个type字段。类型参考不同的表，例如FacebookUsers或GoogleUsers，每个具有user_id场-其具有外国相对于Users.id场-和其他领域，如first_name，profile_picture等。

然而：

1. 我不确定使用这种方法有多聪明。
2. 我不知道如何以这种方法实现第三种场景。

通过将表放置在 SQL Server 中的不同架构中进行查询时是否会影响性能。

例如，如果我有 2 个表，Table1和Table2，并将Table1放入测试模式，将Table2放入历史模式，然后我尝试链接查询中的表，这是否比将 2 个表放在同一个表中慢？架构？

我的数据库包含 200 多个表。当我想修改或插入一个表时，我发现在所有这些表中很难找到它。

• 有没有办法在我的数据库内的文件夹结构中收集相关表？我有几组文件夹，每个文件夹都包含我的应用程序某个部分的表。
• 如果这是不可能的，我如何管理所有这些表并让自己变得容易？

首先让我们说，我是 PSQL 的新手并且来自 MSSQL 背景。我开始在 PSQL 中设计一个数据库。

所以我的主要目标是在这个数据库中有一个主模式，我将用它来控制某些服务，并有多个模式链接到这个，这将是不同的客户端数据。

我已经阅读了表继承，但从来没有遇到过任何人使用继承的效果类似于 DB Migrations 的效果。我想要实现的基本上是有一个默认架构，客户端架构都继承自默认架构。这对我来说，只需更改一个模式，就可以控制创建/删除/更改所有模式的对象。

这可行吗？有没有其他人有过做类似事情的经验？有人有什么建议吗？

更新

这就是我所做的。但是，我的印象是，如果您查看下面的代码，我需要做的就是模式“client1”，但是我错了。:D

所以无论如何，下面是我所做的脚本，它应该处理我现在需要的一切 - 我将使用脚本作为“client2”模式。是好是坏？

-- public schema --
CREATE TABLE public.Users (
   Id bigserial primary key,
   Login text unique,
   check (false) NO INHERIT 
);

CREATE TABLE public.Roles (
   Id bigserial primary key,
   RoleName text unique,
   check (false) NO INHERIT 
);

CREATE TABLE public.UserRoles (
   Id bigserial primary key,
   UserId bigint references users(id),
   RoleId bigint references roles(id),
   unique (UserId, RoleId),
   check (false) NO INHERIT 
);


-- client1 …

我正在尝试比较两个 MySQL 转储文件。一个是通过全新安装的 Web 应用程序制作的，另一个是来自同一 Web 应用程序的转储，该应用程序已从先前版本升级到与全新安装相同的版本号。

基本上我想确保升级脚本正常工作，并且所有正确的列和约束都在升级版本中，就像它们在全新安装中一样。我认为一个简单的 diff/sdiff 就足够了，但我遇到了问题：列顺序。

全新安装和升级之间的列顺序不同，导致许多误报“差异”。在查看输出时很容易看出同一列只是在不同的位置，但是对于数百个表，检查和识别这些误报需要很长时间。

是否有更好的方法来比较这两个将忽略列顺序的转储（或强制转储具有按字母顺序或类似顺序排列的列的方法）或一种更好的完全不同的方法。无可否认，我对 MySQL 还是很陌生，并且正在学习，所以任何帮助都将不胜感激。

谢谢。

我试图在可搜索性和速度之间取得很好的平衡。我正在尝试不同的方法。

选项 1：将数组序列化为 JSON/PHP 序列化数组并将其存储在“元”列中。

   id  |  name   | meta  
1       Bob       {"city":"GoTown","birthdate":"1980\/8\/14","cat":"Felix"}
2       Alice     {"city":"Streamville","birthdate":"1986\/6\/6","dog":"Rex"}

选项 2：将键和值一起存储在堆栈中。

user_id  |    key   |   value   
1         name       Bob
1         city       GoTown
1         birthdate  1980/8/14
1         cat        Felix
2         name       Alice
2         city       Streamville
2         birthdate  1986/6/6
2         dog        Rex

选项 3：3 个表：实体、键、值。每个键名只存储一次。

user_id  |   name   
1         Bob
2         Alice

key_id   |   keyname   
1         city
2         birthdate
3         cat
4         dog

user_id   |   key_id   |   value
1          1            GoTown
1          2            1980/8/14
1 …

SQL Server 用户的设置之一是DEFAULT_SCHEMA. 这是经常dbo但并非总是如此。我意识到您可以使用以下代码更改设置：

ALTER USER [UserName] WITH DEFAULT_SCHEMA = [SchemaName]

据我所知，无论何时我创建 aUSER并且不指定DEFAULT_SCHEMA它使用的 a dbo。但我仍然发现USERS它具有不同的默认架构。

如果我没记错的话，当您有一个从 SQL 2000 升级的实例时，默认架构是与用户名匹配的架构。我猜这就是我所看到的大部分（如果不是全部）的来源。

有没有其他方法可以在USER不指定的情况下创建 aDEFAULT_SCHEMA并使用除 之外的其他内容创建它dbo？

注意：这适用于 SQL Server 2005 及更高版本。

我想在数据库的 schema1 上向用户 A 授予 Create 、 alter 和 drop 权限。我想这个问题已经被问到了，我发现的是将更改授予架构并将创建表授予用户 A： GRANT ALTER, DELETE, EXECUTE, INSERT, SELECT, UPDATE ON SCHEMA::schema1 TO user A;

GRANT CREATE TABLE TO User A;

如果这是正确的，那么 userA 是否也可以在其他模式上创建表？

我有一个数据库设计，但在处理两个表时遇到了问题。我有一个用户表和一个属性表。该属性表可仅具有0,1，或2个用户，让我们称他们的所有者和租户，并且仅在每个中的一个（每属性），和一个用户可以是雇主或在许多房客属性。

因此，根据案例，这是我的两个选择：

1. 在Properties表中有两个外键（因为一个属性引用的最大用户数是 2 而不是 N），称为 owner_id 和tenant_id，它们引用了Users表。
2. 有一个 N:M 中间表，包含 user_id 和 property_id，以及指示该属性中用户类型的另一列（比如布尔值 1 = 所有者，0 = 租户）。

哪个是最好的设计选择？

说明：

• 一个用户有一个姓名和电子邮件，以及财产一条街以及其作为属性数。
• 一个用户可能只是在业主或租客财产，而不是两个，因为所有者意味着他拥有的财产（阉，他住在这里与否），与租客是另一个用户实际上生活在那里的，所以需要有一个老板在添加租户之前。
• 一个属性可能没有用户分配。