我认为这是一件不该做的事.而且，所以，我从来没有做过.然后我看到 FriendFeed 这样做并且实际上使他们的数据库规模更好并减少了延迟.我很好奇我是否应该这样做.如果是这样，正确的做法是什么?
I thought this was a n00b thing to do. And, so, I've never done it. Then I saw that FriendFeed did this and actually made their DB scale better and decreased latency. I'm curious if I should do this. And, if so, what's the right way to do it?
基本上，学习如何将所有内容作为 CouchDB 类型的数据库存储在 MySQL 中的好地方是什么?将所有内容存储为 JSON 似乎更容易、更快捷(无需构建，延迟更少).
Basically, what's a good place to learn how to store everything in MySQL as a CouchDB sort of DB? Storing everything as JSON seems like it'd be easier and quicker (not to build, less latency).
另外，以 JSON 形式存储在 DB 上的内容是否易于编辑、删除等?
Also, is it easy to edit, delete, etc., things stored as JSON on the DB?
CouchDB 和 MySQL 是两种截然不同的野兽.JSON 是在 CouchDB 中存储内容的原生方式.在 MySQL 中，您能做的最好的事情是将 JSON 数据作为文本存储在单个字段中.这将完全违背将其存储在 RDBMS 中的目的，并且会使每个数据库事务变得非常复杂.
CouchDB and MySQL are two very different beasts. JSON is the native way to store stuff in CouchDB. In MySQL, the best you could do is store JSON data as text in a single field. This would entirely defeat the purpose of storing it in an RDBMS and would greatly complicate every database transaction.
不要.
话虽如此，FriendFeed 似乎在 MySQL 之上使用了极其自定义的架构.这实际上取决于您究竟想要存储什么，关于如何滥用数据库系统几乎没有一个明确的答案，因此这对您来说很有意义.鉴于这篇文章已经很老了，他们反对 Mongo 和 Couch 的主要原因是不成熟，如果 MySQL 不为你剪掉它，我会重新评估这两个.他们现在应该成长了很多.
Having said that, FriendFeed seemed to use an extremely custom schema on top of MySQL. It really depends on what exactly you want to store, there's hardly one definite answer on how to abuse a database system so it makes sense for you. Given that the article is very old and their main reason against Mongo and Couch was immaturity, I'd re-evaluate these two if MySQL doesn't cut it for you. They should have grown a lot by now.
这篇关于将数据以 JSON 格式存储在 MySQL 中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！