|
如证据所示,他们陷入了1970年以前的ISAM技术.这就是他们所理解的一切,而这就是他们所能教导的一切.它们使用SQL数据库容器,以便于访问,恢复,备份等,但内容是纯记录文件系统,没有关系完整性,功能或速度. AFAIC,这是一个严重的欺诈行为.
当然,除了ID字段之外,有几个项目是关键的关系或非关键概念,它们结合在一起,使我形成如此严肃的结论.其他项目超出了本文的范围.
一对特殊的白痴目前正在对First Normal Form进行攻击.他们属于庇护所.
回答
现在问你的其余部分.
Is there a way that I can create a relational table without losing auto increment features?
这是一个自相矛盾的句子.我相信你会从我的解释中理解,关系表不需要AUTOINCREMENT“功能”;如果文件具有AUTOINCREMENT,则它不是Relational表.
AUTOINCREMENT仅适用于一件事：当且仅当您想要在SQL数据库容器中创建Excel电子表格时,在顶部填充名为A,B和C的字段,并在左侧记录数字.在数据库术语中,这是SELECT(数据的展平视图)的结果,而不是数据源,它是有组织的(规范化的).
Another possible (but not preffered) solution may be there is another primary key in the first table,which is the username of the user,not with an auto increment statement,of course. Is it inevitable?
在技??术工作中,我们不关心偏好,因为这是主观的,并且它一直在变化.我们关心技术的正确性,因为这是客观的,并且不会改变.
是的,这是不可避免的.因为这只是时间问题;错误数量;数量“不能dos”;用户尖叫的数量,直到你面对事实,克服你的虚假声明,并意识到：
>确保用户行唯一的唯一方法是user_names是唯一的,就是在它上面声明一个UNIQUE约束
>并删除用户文件中的user_id或id
>将user_name提升为PRIMARY KEY
是的,因为你的第三个表的整个问题,而不是巧合,然后被消除.
第三个表是关联表.唯一需要的密钥(主密钥)是两个父主密钥的组合.这确保了行的唯一性,这些行由其密钥标识,而不是由其ID标识.
我正在警告你,因为同样的“老师”教你实现ID字段的错误,教会在关联表中实现ID字段的错误,就像普通表一样,它是多余的,没有任何意义,引入重复,并导致混淆.它是双重多余的,因为提供的两把钥匙已经存在,盯着我们.
由于他们不理解RM或关系术语,因此他们将关联表称为“链接”或“映射”表.如果他们有ID字段,实际上就是文件.
查找表
对于查找或引用表,ID字段尤其愚蠢.它们中的大多数具有可识别的代码,因此不需要枚举其中的代码列表,因为代码(应该)是唯一的.
此外,将子表中的代码作为FK,是一件好事：代码更有意义,它通常会节省不必要的连接：
SELECT ...
FROM child_table -- not the lookup table
WHERE gender_code = "M" -- FK in the child,PK in the lookup
代替：
SELECT ...
FROM child_table
WHERE gender_id = 6 -- meaningless to the maintainer
或者更糟：
SELECT ...
FROM child_table C -- that you are trying to determine
JOIN lookup_table L
ON C.gender_id = L.gender_id
WHERE L.gender_code = "M" -- meaningful,known
请注意,这是您无法避免的：您需要查找代码的唯一性和描述的唯一性.这是防止两列中每一列重复的唯一方法：
CREATE TABLE gender (
gender_code CHAR(2) NOT NULL,name CHAR(30) NOT NULL
CONSTRAINT PK
PRIMARY KEY ( gender_code )
CONSTRAINT AK
UNIQUE ( name )
)
完整的例子
根据您问题中的详细信息,我怀疑您有SQL语法和FK定义问题,因此我将提供您需要的整个解决方案作为示例(因为您没有给出文件定义)：
CREATE TABLE user ( -- Typical Identifying Table
user_name CHAR(16) NOT NULL,-- Short PK
name_first CHAR(30) NOT NULL,-- Alt Key.1
name_last CHAR(30) NOT NULL,-- Alt Key.2
birth_date DATE NOT NULL -- Alt Key.3
CONSTRAINT PK -- unique user_name
PRIMARY KEY ( user_name )
CONSTRAINT AK -- unique person identification
PRIMARY KEY ( name_last,name_first,birth_date )
)
CREATE TABLE sport ( -- Typical Lookup Table
sport_code CHAR(4) NOT NULL,-- PK Short code
name CHAR(30) NOT NULL -- AK
CONSTRAINT PK
PRIMARY KEY ( sport_code )
CONSTRAINT AK
PRIMARY KEY ( name )
)
CREATE TABLE user_sport ( -- Typical Associative Table
user_name CHAR(16) NOT NULL,-- PK.1,FK
sport_code CHAR(4) NOT NULL,-- PK.2,FK
start_date DATE NOT NULL
CONSTRAINT PK
PRIMARY KEY ( user_name,sport_code )
CONSTRAINT user_plays_sport_fk
FOREIGN KEY ( user_name )
REFERENCES user ( user_name )
CONSTRAINT sport_occupies_user_fk
FOREIGN KEY ( sport_code )
REFERENCES sport ( sport_code )
)
在那里,PRIMARY KEY声明是诚实的,它是一个主键;没有身份证;没有AUTOINCREMENT;没有额外的指数;没有重复的行;没有错误的期望;没有相应的问题.
数据模型
以下是与定义一起使用的数据模型. （编辑：常州站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
