1

我正在尝试了解有关数据库交互的更多信息，这让我开发了一个本地应用程序以开始使用。嗯，基本上，到目前为止，我所做的事情有一些不同的结果，我改变了很多东西，我什至不确定我现在改变了什么，哈哈。我不太确定我的一张桌子是否正确，所以我决定重新开始。这就是我希望我愚蠢的本地应用程序做的事情。

  • 最多存储 9 个特定的 RSS 提要（我之前做过 url/链接，但我不想被我以前做过的任何事情弄糊涂，所以我将其更改为 RSS 提要）
  • 默认情况下将填充 1 个提要（因此每个用户都有一个共同提要 - 他们可以更改）
  • 提要应存储在某种排序方案中，以便可以按照输入的顺序检索/打印它们。

将有一个带有 9 个文本字段的编辑屏幕，由相应的数据库条目填充，如下所示：

feed 1: <input type="text" value="http://rss.news.yahoo.com/rss/topstories"> **the default feed for everyone, but they can change it**
feed 2: <input type="text" value="http://content.usatoday.com">
feed 3: <input type="text" value="http://newsrss.bbc.co.uk/rss/newsonl.../world/rss.xml">
feed 4: <input type="text" value="">
feed 5: <input type="text" value="">
feed 6: <input type="text" value="">
feed 7: <input type="text" value="">
feed 8: <input type="text" value="">
feed 9: <input type="text" value="">
        <input type="submit" value="update">

我希望能够在此处编辑/添加新提要并以相同的顺序检索这些提要 - 这是我之前尝试中困惑的一个重要原因。

将有一个输出屏幕以相同的顺序输出提要 URL。

我有 2 个表，users和 now feeds，我相信我的 users 表很好，它基本上存储了一些个人信息。我认为那里的一切都应该很明显。“状态”列将存储来自选择/下拉列表的 2 个字符的状态缩写，我已将其编入索引，因为我希望能够按状态搜索用户。我在检索/编辑/更新该数据时没有任何问题。

CREATE TABLE users (
    user_id              SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
    first_name           VARCHAR(20) NOT NULL,
    last_name            VARCHAR(40) NOT NULL,
    state                CHAR(2) NOT NULL,
    email                VARCHAR(60) NOT NULL,
    pass                 CHAR(32) NOT NULL,
    registration_date    DATETIME NOT NULL,

    PRIMARY KEY(user_id),
    UNIQUE (email),
    INDEX login (email, pass),
    INDEX state (state)                              
);

这是我的新提要表

CREATE TABLE feeds (
    user_id      SMALLINT UNSIGNED NOT NULL,
    feed_url     VARCHAR(255) NOT NULL DEFAULT 'http://rss.news.yahoo.com/rss/topstories',
    feed_id      SMALLINT UNSIGNED NOT NULL DEFAULT 1,

    PRIMARY KEY(user_id, feed_url)                                                                          
);

当用户输入新的提要时，假设提要 #2，该值将插入到 feed_url 中，而 feed_id 将插入值为2。如果输入 feed #3，则 feed_id 将插入值为3。那应该给我一些东西来 ORDER BY 来按顺序检索记录，对吧？

数据编辑屏幕应始终显示提要的输入方式。
数据输出屏幕应始终显示提要的输入方式。

那么，这看起来合适吗？我错过了一些东西吗？我的 feed_url VARCHAR(255) 可能不是万无一失的，但我只会使用短网址进行测试。它也总是很容易被撞到。

4

3 回答 3

1

由于您的提要表将为您的所有用户保存提要，因此您可能需要重新考虑这一点。

您已将 feed_id 的默认值设置为 1，因此您将获得 1 的所有内容 - 在为用户添加第二个提要时您不会获得 2。你需要逻辑。

也许当用户创建一个新的提要时，您会查询他们的所有记录，找到最高的提要 ID，然后将其加 1。然后，您将使用它作为您的新提要 ID。

要找到你的最高 id，你会做类似的事情（语法可能是错误的，我通常是 T-SQL）

从 user_id = @user_id 的提要中选择 max(feed_id)

我从来没有做过任何事情，让用户订购物品，所以你可能想在决定任何事情之前先调查一下。

于 2009-01-10T00:09:13.877 回答
0

忘记最后一篇文章 - 我认为您需要能够重新订购您的提要。如果没有，您只需将 auto_increment 添加到该 feed-id 字段。然后使用 ORDER BY feed-id 升序。

于 2009-01-10T00:14:12.103 回答
0

为了强制每个用户都有一个他们可以更改的初始默认提要的功能，我建议您删除feeds表中的默认值并在应用程序代码中实现该功能。在创建（注册）新用户的代码中，将行添加到users表中，然后将行添加到feeds包含此用户的第一个提要的表中，并使用默认 URL（您可以将其存储在应用程序配置设置中）。

如果您必须保持提要的顺序，那么有两个主要选项。使用您的feed_id列，但将其填充为自动增量。但是，这在某些情况下可能会中断（不能保证总是增加）。另一种选择是更改feed_id为feed_sequence并从您的代码中填充它，使其始终为每个用户的 1-9。

我发现您要求保留提要 URL 的顺序（显然不惜一切代价）是非常不典型的。为什么需要它，为什么它如此重要？

users我注意到你的桌子有几个问题。一方面，该email领域不够大（60 太小了，320 是我认为的真正最大值）。另一方面，我想知道您是否存储pass为纯文本，这将是一个巨大的安全问题。我还注意到它pass被声明为CHAR而不是VARCHAR. 您没有说，但是您的使用是否CHAR表明您没有将密码存储为纯文本，而是将其混淆为固定大小（32）的字段？

当然，提要 URL 也很容易超过 255 个字符。

很高兴看到您已经合理地规范了您的数据，例如通过不做feedUrl1...feedUrl9列。

最好的祝愿。

于 2009-01-27T20:50:45.417 回答