MySQL 头疼,该不该?

发布于 2024-08-20 14:19:39 字数 795 浏览 6 评论 0原文

我有一个分类广告网站。 我正在使用 SOLR 来索引和存储数据。然后我还有一个 MySQL 数据库,其中包含一些有关我不存储或索引的分类的更多信息。

现在,我有一个非常标准化的数据库,有 4 个表。

每当在网站上搜索广告时,SOLR 都会进行搜索并返回一个 ID_number 数组,然后将其用于查询 mysql。 因此 solr 返回 id:s,然后使用该 id:s 从 mysql 数据库获取具有这些 id:s 的所有广告。

现在,我的表之间的所有 JOIN 和关系都让我头疼。

除了易于维护之外,拥有标准化数据库还能得到什么?

我知道,将所有信息存储到一张包含 50 列的表中。

这个来代替查找一个广告并显示它:

SELECT 
  category_option.option_name,
  option_values.value 
FROM classified, category_option, option_values 
WHERE classified.classified_id=?id 
AND classified.cat_id=category_options.cat_id 
AND option_values.option_id=category_options.option_id

因此,我可以使用

SELECT * FROM table_name WHERE classified_id = $classified_id

最后一个实际上不是更快吗? 或者规范化的数据库执行速度更快吗?

谢谢

I have a classifieds website.
I am using SOLR for indexing and storing data. Then I also have a MySQL db with some more information about the classified which I dont store or index.

Now, I have a pretty normalized db with 4 tables.

Whenever ads are searched on the website, SOLR does the searching and returns an array of ID_numbers which will then be used to query mysql.
So solr returns id:s, which are then used to get all ads from the mysql db with THOSE id:s.

Now, all the JOIN and relations between my tables gives me a headache.

What except for maintanance-ease do I get for having a normalized db?

I could you know, store all info into one table with some 50 columns.

So instead of this for finding one ad and displaying it:

SELECT 
  category_option.option_name,
  option_values.value 
FROM classified, category_option, option_values 
WHERE classified.classified_id=?id 
AND classified.cat_id=category_options.cat_id 
AND option_values.option_id=category_options.option_id

I could use this:

SELECT * FROM table_name WHERE classified_id = $classified_id

Isn't the last one actually faster?
Or does a normalized db permform faster?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

东风软 2024-08-27 14:19:39

我建议不要在您的情况下进行非规范化。随着您更多地使用连接,您会变得更好,并且它们开始在您的头脑中变得更加清晰,并且易于维护对未来来说是一个很好的好处。

这里有一个关于规范化(和非规范化)的非常好的链接。 这是一个关于非规范化的问题。一个答案建议使用联接创建一个视图来获取所需的数据,并使用类似于 SELECT * FROM table_name WHEREclassified_id = $classified_id 查询的视图。规范化的数据库可能会更慢,但您不太可能因此而想要非规范化。我希望这能提供一些帮助。

I would advise against denormalizing in your situation. You'll get better with joins as you use them more and they start to become clearer in your head, and maintenance ease is a good benefit for the future.

Here's a pretty good link about normalization (and denormalization). Here's a question about denormalization. One answer suggests creating a view using joins to get the data you need, and using that like your SELECT * FROM table_name WHERE classified_id = $classified_id query. A normalized DB will likely be slower, but it's unlikely you'll want to denormalize for that reason. I hope this provides some help.

土豪我们做朋友吧 2024-08-27 14:19:39

每当进行非规范化时,您通常会提高读取速度并降低写入速度,因为您必须多次写入相同的值。此外,应格外小心保持数据完整性。

  • 查询将被执行多少次?
  • 这是一个高流量应用吗?
  • 可以加个缓存吗?

Whenever you do denormalization you usually gain reading speed and lose write speed, because you have to write the same value many times. Additionally, extra care should be taken to maintain data integrity.

  • How many times the query will be executed?
  • Is this a high traffic application?
  • Can you add a cache?
我只土不豪 2024-08-27 14:19:39

就 MySQL 连接而言,使用 JOIN 的查询是微不足道的。我认为没有必要将其非规范化。

不过,我建议重写它,使其不那么像 PITA 那样可读:

SELECT 
  category_option.option_name,
  option_values.value 
FROM classified
JOIN category_option USING (cat_id)
JOIN option_values USING (option_id)
WHERE classified.classified_id = ?

The query using a JOIN is trivial as far as MySQL joins are concerned. I see no need to denormalize this.

I would however suggest rewriting it to not be such a PITA to read:

SELECT 
  category_option.option_name,
  option_values.value 
FROM classified
JOIN category_option USING (cat_id)
JOIN option_values USING (option_id)
WHERE classified.classified_id = ?
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文