Улучшить SQL-запросы в DDL

Улучшения сделаны

  1. nvarchar(5000) -> nvarchar(4000), НО nvarchar в PostgreSQL => ТЕКСТ
  2. ограничения памяти для некоторых переменных
  3. синтаксис немного изменился на более читаемый
  4. штрихи к подчеркиванию
  5. Улучшения Магнуса

Я следую своему плану для моего первого проекта базы данных.

Я хотел бы знать какие-либо недостатки в запросах и в реляционной таблице.

SQL-запросы в DDL

CREATE TABLE answers 
(
    question_id INTEGER FOREIGN KEY REFERENCES questions(user_id)
                        PRIMARY KEY 
                        CHECK (user_id>0), 
    answer TEXT NOT NULL      -- answer must have text
);

CREATE TABLE questions 
(
    user_id INTEGER FOREIGN KEY 
                    REFERENCES user_info(user_id) 
                    PRIMARY KEY 
                    CHECK (user_id>0), 
    question_id INTEGER FOREIGN KEY REFERENCES tags(question_id) 
                        NOT NULL 
                        CHECK (user_id>0)
                        SERIAL, 
    body TEXT NOT NULL,                    -- question must have body 
    title VARCHAR(60) NOT NULL,            -- no empty title
    moderator_removal BOOLEAN NOT NULL,    -- by default false
    sent_time TIMESTAMP NOT NULL
);

CREATE TABLE tags 
(
    question_id INTEGER FOREIGN KEY REFERENCES questions(question_id) 
                        CHECK (user_id>0), 
    tag VARCHAR(20) NOT NULL,
    CONSTRAINT no_duplicate_tag UNIQUE (question_id,tag)
)


CREATE TABLE user_infos 
(
    user_id INTEGER FOREIGN KEY REFERENCES questions(user_id) 
                    PRIMARY KEY 
                    CHECK (user_id>0)
                    SERIAL
                    UNIQUE, 
    username VARCHAR(25),
    email VARCHAR(320) NOT NULL       -- maximun possible
                       UNIQUE,
    password_sha512 INTEGER NOT NULL,
    is_moderator BOOLEAN NOT NULL,
    is_Login BOOLEAN NOT NULL,
    has_been_sent_a_moderator_message BOOLEAN NOT NULL
);



-- to have default values

ALTER TABLE questions ALTER COLUMN moderator_removal SET DEFAULT FALSE

ALTER TABLE user_info ALTER COLUMN is_moderator SET DEFAULT FALSE
ALTER TABLE user_info ALTER COLUMN is_login SET DEFAULT FALSE
ALTER TABLE user_info ALTER COLUMN has_been_sent_a_moderator_message SET DEFAULT FALSE


-- to have default values

ALTER TABLE questions ALTER COLUMN moderator_removal SET DEFAULT FALSE

ALTER TABLE user_info ALTER COLUMN is_moderator SET DEFAULT FALSE
ALTER TABLE user_info ALTER COLUMN is_login SET DEFAULT FALSE
ALTER TABLE user_info ALTER COLUMN has_been_sent_a_moderator_message SET DEFAULT FALSE

Реляционная таблица

http://files.getdropbox.com/u/175564/db/db777.png

Что бы вы улучшили в запросах DDL?

1 ответ

Решение

Когда вы используете varchar(4000) и так, является ли 4000 фактически концептуальным максимумом того, как долго может быть строка? Или вы просто выбрали что-то "достаточно большое для всего"? Если второе, просто используйте текстовый тип данных. Это будет так же быстро (на самом деле, чуть-чуть быстрее, но вы вряд ли сможете это измерить).

Похоже, что sent_time должен быть timestamptz. Не храните дату / время в varchar.

auto_increment отсутствует в postgres, используйте последовательный столбец.

У вас есть круговая ссылка между тегами и вопросами, что, я уверен, вы не собирались. И ваше проверочное ограничение на Questions.question_id появляется проверяет user_id - слишком много копий / вставок, я готов поспорить.

Наконец, не используйте смешанные идентификаторы. Делайте все строчными, чтобы вам не приходилось их цитировать. Например, используйте строчные буквы для имен столбцов и таблиц.

Другие вопросы по тегам