管理大型用户上传数据集的模式？
我是一个相对菜鸟的程序员。我正在创建基于 Web 的 GIS 工具，用户可以在其中上传 10 行到 100 万行的自定义数据集。数据集可以具有可变列和数据类型。您如何管理这些用户提交的数据集？
每个数据集创建一个表是一个坏主意吗？ （顺便说一句 - 我将使用 postgresql 作为数据库）。
如果这个问题已经在某个地方得到了回答，我很抱歉，但我的搜索没有找到任何好的结果。我可能在搜索中使用了错误的关键字。
谢谢！
I'm a relatively noob programmer. I am creating web based GIS tool where users can upload custom datasets ranging from 10 rows to 1million. The datasets can have variable columns and datatypes. How do you manage these user submitted datasets?
Is the creation of a table per dataset a bad idea? (BTW - i'll be using postgresql as the database).
My apologies if this is already answered somewhere, but my search did not turn up any good results. I may be using bad keywords in my search.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为每个数据集创建一个表根本不是一个“坏”主意。 swivel.com 是一个与您所描述的非常相似的应用程序，我们使用每个数据集的表，它非常适合在用户上传的数据集上生成图形以及使用联接比较跨数据集的数据。我们有超过 10k 个数据集和近 100 万个图表，有些数据集非常大。
您还可以从 Orm 层中获得大量免费使用，例如，我们可以使用活动记录来处理数据集（每个数据集是生成的模型类，其表设置为实际表），
明智的陷阱是您需要做很多事情如果您有任何类型的跨数据集计算，则连接的数量。
creating a table per dataset is not a 'bad' idea at all. swivel.com was a very similar app to what you are describing and we used table per dataset and it worked very well for graph generation on user uploaded datasets and comparing data across datasets using joins. we had over 10k datasets and close to a million graphs and some datasets were very large.
you also get lots of free usage out of your orm layer, for instance we could use active record for working with a dataset (each dataset is a generated model class with its table set to the actual table)
pitfall wise is you gotta do a LOT of joins if you have any kind of cross dataset calculations.
我和我的同事最近解决了一个类似的问题，我们在 MySQL 中的数据模型很差，并且正在寻找更好的方法来实现它。我们权衡了几个不同的选项，包括 MongoDB，最终选择使用实体属性值模型。 EAV 模型本质上是一个 3 列模型。它允许我们用一个模型来表示可变数量的列和数据类型。
您可以阅读一些关于 我们的问题在这里，但听起来它可能也适合你。
My coworkers and I recently tackled a similar problem where we had a poor data model in MySQL and were looking for better ways to implement it. We weighed a few different options, including MongoDB, and ended up using the entity attribute value model. The EAV model is essentially a 3-column model. It allowed us to a single model to represent a variable number of columns and data types.
You can read a little about our problem here, but it sounds like it might be a good fit for you too.