brocaar opened a new issue, #1381:
URL: https://github.com/apache/answer/issues/1381
I was looking at the data-structure of Apache Answer, and I noticed that
there are no foreign-key constraints between the tables. For example, the
`answer` table structure looks like this (in PostgreSQL):
```
\d answer
Table "public.answer"
Column | Type | Collation | Nullable |
Default
-------------------+-----------------------------+-----------+----------+------------------------------------
id | bigint | | not null |
nextval('answer_id_seq'::regclass)
created_at | timestamp without time zone | | not null |
CURRENT_TIMESTAMP
updated_at | timestamp without time zone | | |
question_id | bigint | | not null | 0
user_id | bigint | | not null | 0
last_edit_user_id | bigint | | not null | 0
original_text | text | | not null |
parsed_text | text | | not null |
status | integer | | not null | 1
adopted | integer | | not null | 1
comment_count | integer | | not null | 0
vote_count | integer | | not null | 0
revision_id | bigint | | not null | 0
Indexes:
"answer_pkey" PRIMARY KEY, btree (id)
"IDX_answer_user_id" btree (user_id)
```
E.g. in this case I would have expected:
* `question_id` referencing the `question` table
* `user_id` referencing the `user` table
* ...
I would expect that this could lead to inconsistencies on the log run. E.g.
the `user_id` might no longer exists if the user was deleted (and can not be
nullable), but the application logic did not delete records referencing the
user.
Unless this is a design decision, I think FK constrains should be added to
guarantee data consistency between tables.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
