为预定帐户和可能的写入设计SQL数据库
我正在尝试找出处理以下情况的最佳方法：
为了解决这个问题，这种情况过于简单了。假设我有3个表：交易，账户和指定。
交易表有一个名为 Trans_TransId 的主键并跟踪与交易相关的所有联系信息。
帐户表包含预定义帐户的列表。它有一个名为 Acc_Code 的主键和一个名为 Acc_Val 的描述栏
名称表是一个关系表，其中包含 Trans_TransId ，引用交易表中的主键， Acc_Code 引用 Accounts 表中的主键，以及 Des_Amount ，它是指定给该交易的特定帐户的装载。此表允许每次交易对不同的帐户进行多次指定（ Trans_TransId ）。
此设计适用于用户仅使用预定义帐户的情况列表。但是，我还需要适应一种情况，即用户希望为某个帐户指定一笔金额，该金额不在帐户表中，并且他/她将为此提供说明通过文本框。
在您看来，为了适应这些自定义帐户，设计此数据库的最佳方法是什么？
I''m trying figure out the best way to deal with the following situations:
This scenario is oversimplified for the sake of the question. Let''s say I have 3 tables: Transactions, Accounts and Designations.
Transactions table has an primary key called Trans_TransId and keeps track of all contact information associated with a transaction.
Accounts table contains a list of predefined accounts. It has a primary key called Acc_Code and a description column named Acc_Val
Designations table is a relations table which consists of a Trans_TransId, referencing a primary key from Transactions table, Acc_Code referencing a primary key from Accounts table, and Des_Amount which is an mount designated to a particular account for that transaction. This table allows for multiple designations to different accounts to be made per transaction (Trans_TransId).
This design accommodates situations in which the user uses only predefined accounts from the list. However, I also need to accommodate a situation in which the user would like to designate an amount to a certain account that''s not in the the Accounts table and for which he/she will provide a description via a text box.
In your opinion, what''s the best way to design this database in order to accommodate for those custom accounts?
为了整体数据的完整性，我建议无论如何都要在表格中保留所有这些数据。某些元素在当时可能看起来是暂时的和不重要的，但如果存储的交易与不存在的账户有关，则基础数据本身并不具有参考价值。
我怀疑你可能仍然需要不同地考虑更永久的帐户。在这种情况下，您可以在表格中引入一个标记，以指示该帐户是永久性的还是暂时性的。
如果数据未被存储，您会遇到报告/查询的问题包括事务单独返回其总数为A的值，但对同一数据的报告/查询，但包括链接的帐户信息，返回值B.
For the integrity of your overall data, I would suggest maintaining all this data in the tables anyway. Certain elements may appear transitory and unimportant at the time, but the underlying data will not be inherently referential if transactions are stored pertaining to accounts that are not.
I suspect you may nevertheless need to consider the more permanent accounts differently. In that case you can introduce a flag into the table to indicate whether the account is considered permanent or transitory.
If the data isn''t stored you get problems where a report/query including the transactions alone returns values whose total is A, yet a report/query on the same data, but including the linked Account information, returns a value of B.
我不能维护所有这些帐户，因为有太多，我们不希望显示所有这些帐户供用户选择。我们确实希望给他们一个自己编写的选项，因为我们可以手动匹配到合适的帐户。我只是想弄清楚处理这些写入的最佳方法。
I can''t maintain all of these accounts as there are way too many and we don''t want all of them to be displayed for the user to choose from. We do want to give them an option to write their own in that we can late manually match to an appropriate account. I just want to figure out the best way to deal with these write-ins.
alkos333 ：
我无法维护所有这些帐户，因为有太多的东西...
alkos333:
I can''t maintain all of these accounts as there are way too many ...
太多了。我发现很难想象有太多的SQL Server可以处理。
Too many for what. I find it hard to conceive of there being too many for SQL Server to handle.
alkos333 ：
...我们不希望显示所有这些内容供用户选择。
alkos333:
... and we don''t want all of them to be displayed for the user to choose from.
这可以通过标志轻松处理，以区分官方帐户和您称为写入帐户的帐户。
That can easily be handled by the flag to differentiate those accounts which are official and those that you refer to as write-ins.
alkos333 ：
我们确实想给他们一个自己编写的选项，以后我们可以手动匹配到一个合适的帐户。我只是想弄清楚处理这些写入的最佳方法。
alkos333:
We do want to give them an option to write their own in, that we can later manually match to an appropriate account. I just want to figure out the best way to deal with these write-ins.
请原谅我改写你的报价。我觉得这有助于理解你想说的话。
这当然是新信息。我认为，经过反思，我仍然会推荐相同的方法，但是如果你以后进行手动匹配，那么任何与它们无关的临时账户都可以从你的桌子上削减。
这个新信息还意味着被临时账户超支的可能性大大降低，以至于它几乎不值得考虑作为一个问题（即使你以前认为是这样）。
Excuse my rewriting your quote. I felt it would help to understand what you were trying to say.
This is new information of course. I think, on reflection, I would still recommend the same approach, but if you are doing later manual matching, then any temporary accounts that no longer have anything tied to them could be pared from your table.
This new information also means that the chances of being overrun by temporary accounts are reduced enormously to the point that it''s hardly worth considering as an issue (even if you felt it was before).