数据库结构,存储和组织数据

时间:2018-07-17 04:26:21

标签: mysql database database-design

我正在创建一个跟踪众筹活动的项目,以便最终用户可以分析数据。显然,我正在使用蜘蛛程序定期抓取每个广告系列的所有详细信息,然后将其存储在数据库中。

我只是不确定如何设计数据库。问题是,这些广告系列的使用寿命可能超过一个月,因此我可能每天要多次抓取每个广告系列以检查更改。

将每个市场活动汇总到一个表中是不切实际的,因为将有数千个市场活动,并且从理论上讲,如果一个市场活动的详细信息不断更新,则可能会有数百行。也可能会有数十列。因此,我考虑为每个广告系列创建单独的表格。

同时拥有数千张表格似乎也不切实际,特别是如果用户想要比较几个不同的活动时。为了比较许多广告系列,我将不得不查询无限数量的表。

我以前从未处理过这种复杂性。有人知道如何解决这个问题吗?

潜在字段

CREATE TABLE campaign (
  id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  campaign_url VARCHAR(255) NOT NULL,
  campaign_phase VARCHAR(8) NOT NULL,
  project_website VARCHAR(255) NOT NULL,
  project_facebook_url VARCHAR(255) NULL,
  project_linkedin_url VARCHAR (255) NULL,
  project_twitter_url VARCHAR(255) NULL,
  project_youtube_url VARCHAR(255) NULL,
  product_title TEXT NOT NULL,
  product_tagline TEXT NOT NULL,
  product_phase VARCHAR(10) NULL,
  product_overview TEXT NULL, # may be more columns derived from overview...
  owner_name VARCHAR(255) NOT NULL,
  owner_title VARCHAR(255) NOT NULL,
  owner_description TEXT NULL,
  owner_avatar_url VARCHAR(255) NULL,
  owner_location VARCHAR(255) NOT NULL,
  owner_campaign_count TINYINT NOT NULL,
  owner_total_raised INT NOT NULL,
  owner_other_campaign_urls TEXT NOT NULL, # this may have multiple values...
  owner_contribution_count TINYINT NOT NULL,
  owner_verified BIT NULL,
  # info about team members...
  # info about perks...
  # info about/meta-analysis of campaign text, images, and videos...
  # info about updates...
  # info about backers...
  crawled_on DATETIME NOT NULL
)

值得注意的是,我正在考虑隔离注释所代表的部分,因为其中许多部分可能包含也可能不包含大量信息。另外,带有VARCHAR(255)的字段可能需要使用其他数据类型。

2 个答案:

答案 0 :(得分:1)

(部分答案)

数百列与您显示的相似的列可能有问题。我建议您考虑通过几种方式进行拆分。

  • “团队成员”听起来像是一个人的名单,而不是一个人。因此,那一定是一个单独的表,以1:许多连接。同样,“图像”听起来像是一个开放式列表。
  • 应该将相对静态数据与经常更新的数据分开。
  • 弄清楚您的SELECTs的样子。如果其中一些人查看“产品”列而不是“所有者”列,那么将一个群集列或另一个群集分开可能会有所帮助。
在单个表中的

数百甚至是数百万行都不是问题。一张桌子上的数百个正踩在冰上。

盲目使用(255)可能会咬你。

如果要爬网不同的站点,则极有可能所获得的数据的格式和组成因站点而异。 (我在新闻网站上都这样做过-这是一项全职工作。)

底线:对您的问题没有简单,明显的答案。您将面临挑战。

答案 1 :(得分:0)

使用规范化模式粘贴。除非我们谈论的是极端数据量,否则一张描述您所描述内容的表是好的。恕我直言,在后一种情况下,无论如何,MySQL都不是一个很好的选择。

保持简单:设计一张表,选择正确的数据类型,避免使用可为NULL的列(您提到“数十列和数十列”,这是为了什么?)并正确地为数据建立索引。你不能错过。