标签: relational-database

我有3种类型的用户:

• 管理员
• 供应商
• 雇员

每种用户类型将具有不同的用户界面并访问不同类型的数据.他们唯一的相似之处在于他们使用的是一个Web应用程序,但是他们可以访 将它们全部放在像tbl_users这样的用户表中是否更好？或者创建tbl_admins,tbl_suppliers,tbl_employees是否更好？

主键是为给定表选择的所选候选键吗？

我正在编写一个不一定需要扩展能力的应用程序,因为它不会在开始时收集大量数据.(但是,如果我很幸运,我可能会在路上行驶.)

我将在同一个盒子上运行我的Web服务器和数据库(现在).

话虽如此,我正在寻找性能和效率.

我的应用程序的主要部分将是加载博客文章.使用RDBMS(MySQL)我将进行6次查询(其中2个查询是连接),只是为了加载一个博客文章页面.

select blog
select blog_album
select blog_tags
select blog_notes
select blog_comments (join with users)
select blog_author_participants (join with users)

但是,使用MongoDB,我可以对6个表进行反规范化并将其展平为仅2个表/集合,并将我的查询最小化为可能只有一个查询,

users
blogs
    ->blog_album
    ->blog_tags        
    ->blog_notes
    ->blog_comments
    ->blog_author_participants

现在,使用MongoDB架构,将会有一些数据冗余.但是,硬盘空间比CPU /服务器便宜.

1.)这是一个使用MongoDB的好方案吗？

2.)在扩展到单个服务器之外时,您是否只在使用MongoDB时获益？

3.)使用MongoDB是否存在任何持久性风险？我听说在执行插入时可能会丢失数据 - 因为insert首先写入内存,然后写入数据库.

4.)这是否会阻止我在生产中使用MongoDB？

我想在新项目中开始使用表关系.

经过一些谷歌搜索后,我得到了2个表作为InnoDB:

我要链接的键是

- > users-> userid(primary) - > sessions-> userid(index)

我在这个过程中唯一不理解的是"On update"和"On delete"的不同设置

这里的选项是:

• - (没有？)
• 级联(???)
• 设置Null(将所有内容设置为null？)
• 没有动作(好吧......)
• 限制 (？？？)

我基本上希望在完全删除用户时删除会话中的数据这个会话只会在我的会话管理器检测到到期时删除...

因此,如果有人能告诉我这些选项是做什么的,那将非常感激.

我一直在为在线商店系统设计数据库.通过阅读本网站上的一些帖子,我遇到的问题是,虽然我可以使用复合主键,但我会在下面解释一下,这是不是很糟糕的做法(根据我在这方面阅读的帖子)在stackoveflow上,很多人说这是一个不好的做法所以这就是我要问的原因.

我想在单独的表格中存储订单付款.原因在于,订单可以包含许多项目,这些项目以多对多关系的形式在单独的表格中处理.现在,如果我不使用复合主键作为我的付款表,我将失去我的独特性PaymentID:

[PaymentId] INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
[OrderId] INT NOT NULL PRIMARY KEY --Also a Foreign Key--

现在,如果我只删除主键OrderId,我会在这里丢失我的一对一关系Many OrderIds can be associated to many PaymentIds,我不想要这个.

这就是为什么这里先前提出的问题已经(大多数时候)得出结论,复合键是一个坏主意.所以我想为自己澄清一下; 如果不好,那么最佳做法是什么？

有一个"把FK放到你的父母"的方法,即每个记录指向它的父母.
这是一个难以阅读的操作,但很容易维护.

然后有一个"目录结构键"方法:

0001.0000.0000.0000 main branch 1
0001.0001.0000.0000 child of main branch one
etc

这是超级易读,但难以维护.
有什么其他方式和他们的利弊/专业人士？

在设计用于存储用户设置的表时,以下哪个选项(如果有)被认为是最佳做法？

(选项1)

USER_SETTINGS
-Id
-Code (example "Email_LimitMax")
-Value (example "5")
-UserId

(选项2)

为每个设置创建一个新表,例如,通知设置需要您创建:

"USER_ALERT_SETTINGS"
-Id
-UserId
-EmailAdded (i.e true)
-EmailRemoved 
-PasswordChanged
...
...

"USER_EMAIL_SETTINGS"
-Id
-UserId
-EmailLimitMax
....

(选项3)

"USER"
-Name
...
-ConfigXML

我想知道在关系数据库中使用Triple Stores有什么好处？

何时可以在关系数据库上选择键值数据存储？决定一方或另一方需要考虑哪些因素？什么时候混合最好的路线？如果可以,请提供示例.

我一直在尝试对产品变体进行建模,并认为我可能需要使用EAV.没有EAV,我本可以做到这一点,但我担心我可能会错过一些东西.这是我的设计:

这是我想要表达的内容:

1. A product可以具有0或更多product variants(例如,T恤产品可以具有尺寸和颜色变体).
2. A product variant可以具有1个或更多product variant options(例如,尺寸变体可以是小的,中的,大的).
3. 一个SKU由1个或更多组成product variant options(该product_variant_option_combination表将包含`product_variant_options的所有可能组合.因此,如果有3个大小和3个颜色,那么将有3*3 = 9个组合 - 并且每个组合将被赋予它自己的SKU和价格).
4. A product可以有1个或更多SKUs.

如果产品没有任何变体,那么就忽略了product_variants,product_variant_options和product_variant_option_combinations.

这个设计听起来好吗？我最终会在查询时遇到问题吗？它会扩展吗？它正常化了吗？

更新1

@Edper:

如果产品可以具有0或多个(可选模式)产品变体(例如尺寸,颜色等).是否遵循产品变体还可以有0个或多个具有该变体的产品？

我不这么认为.像"T恤"这样的产品可能具有"尺寸"变体,而像"裤子"这样的产品也可能具有"尺寸"变体,但我认为这只是偶然事件.没有必要使"大小"仅显示为一条记录,因为"大小"可能具有不同的上下文.

我正在处理的产品差异很大,他们必然会有类似命名的变体.

更新2:

以下是我如何查看数据的示例:

我已经将变体Size及其相关值加入了盒子.我想说清楚这些不被认为是重复数据.Size3种产品的变体只是偶然的.我认为没有必要将其正常化.每种产品可以有0个或更多变体 - 我不知道它们.我希望"重复"(虽然它们并不是真正重复,因为它们总是在特定产品的上下文中 - 因此,Widget 1的"Size"变体与Widget 2的"Size"变体不同).

更新3:

我现在看到,在我的设计中,a可能product有多个相同的product_variants.我认为这可以通过制作来解决product_variants.product_id和product_variants.name复合键.这意味着Widget 1只能拥有一次"Size"变体.

product_variant_options.product_variant_id product_variant_options. …