数据库结构问题...严重的帮助只有请 [英] Database Structure Question ... Serious Help Only Pls

问题描述

好的...所以我有一个数据库即时建立来跟踪用户反馈。我遇到的

问题是我们需要跟踪问题。在

反馈中检测到，但我们有多个输入反馈。所以现在，我们

从调查和电子邮件获得反馈。我遇到的问题是将这两个输入链接到一个共同的输入ID。为了

轻松跟踪问题 （每个问题将有一个输入ID

显示问题的来源，无论是来自调查还是

电子邮件）。但是我的问题出现在我进入

调查表的大量进口中。因此，当我在表格中添加一堆数据（通过导入或复制/粘贴）

时，输入ID不会更新，因为必须单独保存

表以链接两个输入。这是否意味着？b $ b感觉？那我该怎么做？！？！这是一个图表。我的桌子：


调查：

- 输入ID（来自输入的FK）

- 日期等


电子邮件

- 输入ID（来自输入的FK）

- 日期等


输入

- 输入ID（PK，自动编号）

- 类型


问题

- 输入ID（来自输入的FK）


所以问题是当我向Survey或电子邮件添加数据时，我不想

手动将数据添加到Input然后回到Survey并输入下一个

生成的自动编号...


这有意义吗？任何想法???

Ok ... so i have a database im building to track user feedback. The
problem im running into is we need to track "Problems" detected in the
feedback, but we have multiple inputs for feedback. So right now, we
get feedback from Surveys and Email. The problem im running into is a
neeeed to link these two input to a common "Input ID" in order to
easily track a "Problem" (each "Problem" will have an "Input ID"
showing the source of the Problem whether it was from a survey or
email). But my problem comes up with large imports that i do into the
survey table. So when i add a bunch of data (by import or copy/paste)
into the table, the Input ID is not updated because that MUST be kept
in a separate table in order to link both inputs. Does that make
sense? So how do i do this?!?! Here''s a "diagram" of my tables:

Survey:
- Input ID (FK from Input)
- Date, etc.

Email
- Input ID (FK from Input)
- Date, etc.

Input
- Input ID (PK,AutoNumber)
- Type

Problem
- Input ID (FK from Input)

So the problem is when i add data to Survey or email, I dont want to
manual add data to Input then go back to Survey and input the next
AutoNumber generated ...

Does this make sense? Any ideas???

推荐答案

它与每个人都有一个字段一样有意义

你的桌子......

****** @ gmail.com博士写道：

It makes about as much sense as having InputID be a field in every one
of your tables...

Dr******@gmail.com wrote:

好​​的...所以我有一个数据库即时建立来跟踪用户反馈。我遇到的

问题是我们需要跟踪问题。在

反馈中检测到，但我们有多个输入反馈。所以现在，我们

从调查和电子邮件获得反馈。我遇到的问题是将这两个输入链接到一个共同的输入ID。为了

轻松跟踪问题 （每个问题将有一个输入ID

显示问题的来源，无论是来自调查还是

电子邮件）。但是我的问题出现在我进入

调查表的大量进口中。因此，当我在表格中添加一堆数据（通过导入或复制/粘贴）

时，输入ID不会更新，因为必须单独保存

表以链接两个输入。这是否意味着？b $ b感觉？那我该怎么做？！？！这是一个图表。我的桌子：


调查：

- 输入ID（来自输入的FK）

- 日期等


电子邮件

- 输入ID（来自输入的FK）

- 日期等


输入

- 输入ID（PK，自动编号）

- 类型


问题

- 输入ID（来自输入的FK）


所以问题是当我向Survey或电子邮件添加数据时，我不想

手动将数据添加到Input然后回到Survey并输入下一个

生成的自动编号...


这有意义吗？有任何想法吗？？？

Ok ... so i have a database im building to track user feedback. The
problem im running into is we need to track "Problems" detected in the
feedback, but we have multiple inputs for feedback. So right now, we
get feedback from Surveys and Email. The problem im running into is a
neeeed to link these two input to a common "Input ID" in order to
easily track a "Problem" (each "Problem" will have an "Input ID"
showing the source of the Problem whether it was from a survey or
email). But my problem comes up with large imports that i do into the
survey table. So when i add a bunch of data (by import or copy/paste)
into the table, the Input ID is not updated because that MUST be kept
in a separate table in order to link both inputs. Does that make
sense? So how do i do this?!?! Here''s a "diagram" of my tables:

Survey:
- Input ID (FK from Input)
- Date, etc.

Email
- Input ID (FK from Input)
- Date, etc.

Input
- Input ID (PK,AutoNumber)
- Type

Problem
- Input ID (FK from Input)

So the problem is when i add data to Survey or email, I dont want to
manual add data to Input then go back to Survey and input the next
AutoNumber generated ...

Does this make sense? Any ideas???

你需要规范化一点。似乎缺少的是反馈源标识符的单一

来源 - 响应

与支持的呼叫/互动。一旦你有了这个，你就可以继承

其他东西，如果你愿意的话。


如果我是你，我会拿出一支笔，纸张然后向后退一步。

描述纸质系统的工作原理（或者你提议的那个系统将如何工作）。确定您可以收集哪些输入以及您想要哪些报告

或您想要从数据库中获取的信息。听起来很简陋，但

报废纸质图纸的成本要比花上几个小时便宜得多。

这些东西永远不会有效。


关键问题是如何将通话/联系与后续

调查联系起来。为什么不在Survey中创建一个外键，将初始联系回复给
？如果必须，您可以将其子类化为

您可以收集特定于每种联系类型的信息，并从

那里开始。 Rebecca Riordan在 www.mvps.org/access 上有一个例子。

You need to normalize a little. What seems to be missing is a single
source of an identifier for the source of the feedback - responding to
a call/interaction with support. Once you have that, you can subclass
the other stuff, if you want.

if I were you, I''d get out a pen and paper and take a step backward.
Describe how the paper-based system works (or how your proposed one
will). Determine what inputs you can gather and what reports you want
or information you want out of your database. Sounds rudimentary, but
it''s a lot cheaper to scrap paper drawings than hours of work on
something that will never work.

The key question is how to link the call/contact with the followup
survey. Why not just create a foreign key in Survey that refers back
to the initial contact? If you have to, you can subclass that out so
you can gather information specific to each contact type and go from
there. There''s an example at www.mvps.org/access by Rebecca Riordan.

Dr******@gmail.com 写道：

Dr******@gmail.com wrote:

调查：

- 输入ID（来自输入的FK）

- 日期等等


电子邮件

- 输入ID（来自输入的FK）

- 日期等


输入

- 输入ID（PK，自动编号）

- 类型


问题

- 输入ID（来自输入的FK）

Survey:
- Input ID (FK from Input)
- Date, etc.

Email
- Input ID (FK from Input)
- Date, etc.

Input
- Input ID (PK,AutoNumber)
- Type

Problem
- Input ID (FK from Input)

您想要仅限严重帮助，就在这里。 8）没有，如果，而且，

或者说，你所展示的设计是不正确的，基本上是没有用的。没有冒犯意味着。


这些应该合并到一个表中。你试图建模的实体是什么？b $ b答案是输入信息。一个实体= 1个表。


尝试这样的事情，而不是：


输入_信息

- 输入_PK

- 日期等

- Input_Type_FK

- Problem_Type_FK

- 问题描述


Input_Type

- Input_Type_PK

- Input_Type（调查，电子邮件等）


Problem_Type

- Problem_Type_PK

- Problem_Type（不同类型问题的标题）


-

Tim http://www.ucs.mun.ca/~tmarshal/

^ o<

/＃）Burp-beep，burp-beep，burp-beep？ - Quaker Jake

/ ^^Whatcha doin？ - 同上TIM-MAY !! - 我

You want "Serious help only", well here it is. 8) There''s no if, and,
or but about it, the design you''ve shown is incorrect and basically
useless. No offence meant.

These should be combined into one table. What''s the entity you''re
trying to model? The answer is input information. One entity = 1 table.

Try something like this, instead:

Input_Information
- Input_PK
- Date, etc
- Input_Type_FK
- Problem_Type_FK
- Problem description

Input_Type
- Input_Type_PK
- Input_Type (Survey, email, etc)

Problem_Type
- Problem_Type_PK
- Problem_Type (headers of different types of problems)

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

这篇关于数据库结构问题...严重的帮助只有请的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！