标签: schema

我们有几个正在开发的数据库，我想开始使用 SQL Server 架构进行权限管理和数据库对象的逻辑分组。在架构属性下有明确的权限，如

Alter
Control
Delete
Execute
...

这些权限的层次结构是什么？这个想法是授予Control管理员 AD 组，并授予开发人员 AD 组一些允许他们完成工作的权限（ddl、读取、写入）。应该赋予开发者什么权利？

几年过去了……但我遇到了一个问题集，它让我想起了模式设计模式，我正在努力回忆细节。

本质上，该模式由一个为所有插入、更新和删除提供服务的3 NF（或其他）数据库组成。在某些定期或事件驱动的基础上，它会将其全部（或部分）状态发布到另一个针对高性能只读访问进行了优化的数据库。本质上，发布通常针对完全不同或非规范化的模式。

问题是……这是众所周知的模式吗？如果是，它叫什么，除了相同状态的重复存储之外还有什么陷阱。

我们正在构建一个实时银行平台和应用程序。

我们主要关注的是跨多个数据库服务器的数据的安全性和一致性。我们需要事务，我们不能承受断电和丢失数据的风险（我说的是 MongoDB）。我们的次要关注是架构 - 为我们的应用程序租户用户提供的功能。

我们还想避开大型数据库上的模式更新地狱。我们租户的自定义架构是可选的，但非常可取。

我们是非常重的 AJAX 前端，我们的后端是完整的 nodejs。我们做了很多 JSON 数据处理。

我们应该使用 MySQL 吗？对于我们的案例，是否有任何 noSQL 解决方案（也许是 CouchDB？）？

感谢您抽出宝贵时间回答这个问题！

这是一个数据库，用户可以在其中创建“项目”并对其进行处理。我们有一个表格project和各种其他表格，其中包含项目的不同属性（每个项目的多行，从 2-30K 行）。所有这些都包含projectID链接到project. 目前数据库是400GB。

我们正在尝试为每个项目创建一个架构，其中每个架构都将包含所有属性表。每当创建一个项目时，它都会获得一个新的模式。这意味着每个表最多包含 30K 行，这将提高select性能。我们将在查询中使用动态 SQL 来读取/插入。

我觉得这不是数据库的正确应用，但我如何向我的团队证明这是一种糟糕的方法？

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 = 租户）。

哪个是最好的设计选择？

说明：

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

我有一个玩具 Cassandra 集群在家里的一些 RaspberryPi 上运行。我目前正在将 CryptoCoin 数据记录到它，希望能更多地了解 Cassandra 以及沿途的其他一些事情。

我今天在这里的问题是找出我是否在这张表上正确构建了我的架构。

该表没有很多字段，主键是名称字段和时间戳字段。我想从所有硬币中查询最近 N 小时的数据（每分钟记录一次数据）。如果我使用简单的 WHERE 子句，我会收到“ALLOW FILTERING”警告。我理解为什么会发生这种情况，但我正在努力理解正确的前进道路以确保可扩展的解决方案。现在该表只有大约 320k 条记录，我可以毫无问题地使用 ALLOW FILTERING，但我意识到情况可能并非总是如此。

我设置了一个测试来查看运行两种不同的查询方法需要多长时间。ALLOW FILTERING 方法目前是最快的，但它可能会保持这种状态吗？这就是我知识匮乏的地方。

我有一个想法，添加另一个字段，即星期几，也可能是月份字段。我的想法是这可能允许在查询中进行更多过滤，因此我不必像下面所做的那样遍历所有代币，但我不知道这是否是个好主意。如果我这样做，我是否将它们设为主键？认为这是我对 Cassandra 最困惑的地方，但并非完全如此；也许只是不够自信。

CQL 表说明：

CREATE TABLE cryptocoindb.worldcoinindex (
    name text,
    timestamp int,
    label text,
    price_btc double,
    price_cny double,
    price_eur double,
    price_gbp double,
    price_rur double,
    price_usd double,
    volume_24h double,
    PRIMARY KEY (name, timestamp)
) WITH CLUSTERING ORDER BY (timestamp ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction …

与在事实表本身中拥有时间属性相比，在星型模式中拥有时间维度有什么好处？

例如：

我有一个交易数据，其中包含每笔交易的用户信息、交易发生的国家和日期。

选项 1 如果我错了，请纠正我，但这可能是广泛使用的方法，也是许多人最推荐的方法：

• 包含transaction_ID(PK)、user_id(FK) 和country_id(FK) 以及 date_id (FK) 的交易事实表

• 包含user_id(PK) 和其他用户属性的用户维度，比方说name& phone_number。

• 由date_id(PK), date, day, month, year, , 组成的日期维度quarter。

选项 2 我只是想而不是选择选项 1，但不确定：

• 包含transaction_ID(PK), user_id (FK) 和country_id(FK), date, day, month, year, 的交易事实表quarter。

• 包含user_id(PK) 和其他用户属性的用户维度，比方说name& phone_number。

选择 1比选择 2有什么好处？我不知道为什么加入另一个 Date 维度会是更好的选择，即使它是最广泛使用的方法。非常感谢！