php - 探索数据建模(如何将合理的数据库组合在一起)

Question

我正在开发一个项目，人们可以在该项目中创建播放列表并将其作为对象存储在 localStorage 中。目前一切都在客户端。

所以我现在想向前迈出一步，制作一个用户登录系统(我可以使用 php mysql 和 fb connect 或 oauth 系统来完成，还有其他建议吗？)。问题是决定我是否为每个用户创建一个 SQL 数据库并存储他们的播放列表(带有媒体信息)，或者是否有其他方法可以解决。处理大量数据库对我来说会是一个麻烦(就速度而言)吗？

我只创建一个数据库怎么样:

用户数据库 ---> 一个表包含 { user(primary key) pass someotherInfo} ，然后每个 USER 表 {包含播放列表) ，每个播放列表第三个表(包含用户 ID 和媒体信息，我的主键是什么？)

示例: 我有 10 个注册用户，每个用户有 2 个播放列表

1.table 1: 10 entries
2.table(s): username - playlists (10 tables) || i make one table with one field user other field playlist name
3.tables: each playlist - media info, owner (20 tables)

或者有更简单的方法吗？

我希望我的问题很清楚。

PS:我是 php 和数据库的新手(所以这可能很愚蠢)

Answer 1

令人惊讶的是，大多数答案似乎都错过了这个问题，但我会尝试一下；

这称为数据建模(如何将数据库中的一堆表组合在一起，以便以尽可能最好的方式表达您想要的内容)，并且不要觉得问这个问题很愚蠢；有些人把所有醒着的时间都花在调整和设计数据模型上。它们对于任何系统的健康都非常重要，事实上，它们比大多数人认为的更重要。

听起来您走在正确的道路上。定义实体并为每个实体创建一个表始终是一个很好的提示，因此在本例中您拥有用户、播放列表和歌曲(例如)。如此定义你的表格；用户、歌曲、播放列表。

接下来是定义字段和表的名称(也许上面建议的简单名称很简单)。有些引入了虚假 namespace (即 MYAPP_USER 而不仅仅是 USER)，特别是如果他们知道数据模型将来会在同一个数据库中扩展和扩展(或者，有些是因为他们知道这是不可避免的)，而另一些则只是闯入无论他们需要什么。

最大的问题永远是关于 normalization以及围绕此的各种问题，平衡性能与适用性，并且有大量关于这个主题的书籍，所以我无法给你任何有意义的答案，但对我来说它的要点是；

表中的数据字段什么时候才值得拥有自己的表？一个例子是，您完全可以创建仅包含一个表、两个表或 6 个表的应用程序，具体取决于您希望如何拆分数据。我认为这就是您的问题的真正所在。

我想说你的假设非常正确，要记住的是一致的命名约定(关于如何命名标识符有很多意见)。对于您的应用程序(使用上面提到的表格)，我会这样做；

USER { id, username, password, name, coffee_preference } 
SONG { id, artist, album, title, genre } 
PLAYLIST { id, userid } 
PLAYLIST_ITEM { id, songid, playlistid, songorder }

现在您可以使用 SQL 获取用户的所有播放列表；

   SELECT * FROM PLAYLIST WHERE userid=$userid

或者获取播放列表中的所有歌曲；

   SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder

等等。再次，关于这个主题已经有很多著作了。这一切都是为了在记下技术解决方案的同时进行清晰的语义思考。有些人只将此作为职业(例如 DBA)。会有很多意见，特别是关于我在这里写的内容。祝你好运。