相当大（400k）mysql数据库设计为多个用户

我正在寻求有经验的管理员的意见。相当大（400k）mysql数据库设计为多个用户

我正在一个网站上工作，在这里你解决单词anagrams。如果它解决了，它不应该再次显示。

Wordbase包含〜400k条目。什么是存储这些数据的最有效的解决方案？

的一种方法是：

+---------+------------------------+ 
| word_id | user1 | user2 | user...| 
+---------+------------------------+ 
| 1  | null | null | 1  | 
| 2  | 1  | null | null | 
| ... |  |  |  | 
| 400000 | null | 1 | null | 
+---------+------------------------+

如果假设1 =解决。

但是它不会很快成为怪物吗？（+即使是一个简单的查询，由一个新用户扩展它永远）

其他解决方案是为所有用户存储每个解决word_id，但它可以为每个条目6位数，并大规模和迅速增长以及。

哪个引擎在这个例子中更有效？ MyISAM或InnoDB？

来源

2016-01-13 Michal z

不是真的增添了这一点，但仍然注释。 400k记录甚至不是很接近被远程相当大 – ChrisBint

@ChrisBint Mysql新手的词汇，对不起:) –

您不会将用户设置为列。如果我理解这个问题，你将有一个表，称为像WordUsers每“字”，一个每个“用户”一行：

create table WordUsers (
    WordUserId int not null primary key auto_increment, 
    WordId int not null, 
    UserId int not null, 
    . . . 
    constraint fk_WordId foreign key (WordId) references Words(WordId), 
    constraint fk_UserId foreign key (UserId) references Users(UserId) 
);

当一个字被显示给用户，那么你添加排到这张桌子。 . . .可以包含其他信息，例如交互的日期/时间。

来源

2016-01-13 13:24:40

是的，我认为把用户作为列是一个很大的禁忌，所以谢谢你澄清 –

'WordUserId int not null primary key auto_increment'是一种浪费;只需要'PRIMARY KEY（WordId，UserId）'。 –

如果你的数据库支持它（我认为他们现在都在做） - 为什么不把一个文本字段放在用户的表上，用一串“N”填充为“否 - 他们没有” t看到这个单词了“，当他们被给出一个单词时，只需将该记录/单词的”N“更改为”Y“并重新保存新的字符串？一个TEXT字符串最长可达65,536个字符。所以你让你的字符串像5000“N”一样。

或者如果你想打败自己一点 - 使用BIT字段，并使其像5000标志。相同的概念，但更难使用。

顺便说一句：在“N”和“Y”的字符串上，你应该可以做一个类似于“WHERE SUBSTR（SEEN_IT，WORD_ID，1）='N''类似测试的SQL查询。

来源

2016-01-13 13:31:27

'TINYTEXT'限于256字节_。 –

@RickJames：你说得对！我应该说使用TEXT而不是TINYTEXT。相应地修改答案。 –

仍然不完全正确 - _bytes_，而不是_characters_。对于utf8，这可能是差异的3倍。 –

-1

您应该使用关系数据库中，像它应该是关系：

CREATE TABLE user(user_id int autoincrement, user CHAR(16)); 
CREATE TABLE word(word_id int autoincrement, word CHAR(16)); 
CREATE TABLE solved(word_id, user_id);

来源

2016-01-22 01:55:14

你能提供一些比“没有任何东西就叫做*关系*数据库”更重要的推理吗？ –

相当大（400k）mysql数据库设计为多个用户

回答

相关问题