2013-12-17 3 views
0

Я хотел бы узнать, правилен ли следующий MySQL.хотите знать, правильно ли SQL

Особенно я хотел бы, чтобы убедиться, что следующие пункты право:

  • первичный ключ поля.
  • Вархар (500) для хранения цитаты (например, известные слова некоторых людей, таких как философы или политики).
  • Внешние ключи.

Большое вам спасибо!

CREATE TABLE quote (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    quote VARCHAR(500) NOT NULL 
); 
CREATE TABLE topic (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, 
    topic VARCHAR(50) NOT NULL, 
    parentTopic INT UNSIGNED, 
    FOREIGN KEY (parentTopic) REFERENCES topic(id) 
); 
CREATE TABLE quoteTopics (
    quote INT UNSIGNED NOT NULL, 
    topic INT UNSIGNED NOT NULL, 
    PRIMARY KEY (quote, topic), 
    FOREIGN KEY (quote) REFERENCES quote(id), 
    FOREIGN KEY (topic) REFERENCES topic(id) 
); 
+2

Возможно, попробуйте выработать слово «правильный» в этом конкретном случае. – DaGardner

+0

Что случилось, когда вы его попробовали? – BWS

+0

Синтаксис ключей различается между серверами sql. Кажется, mysql, потому что у других серверов нет ключевого слова auto_increment. На mysql это кажется правильным. – peterh

ответ

1

Единственное, что я хотел бы предложить использует VARCHAR(MAX) вместо VARCHAR(500), если нет уважительной причины только поддержку 500 символов. Таким образом, вы не будете исчерпывать память так часто, и вы все равно можете использовать текстовые функции, такие как MID, LIKE и т. Д.

+0

Спасибо! Я предполагаю, что varchar не использует все зарезервированное пространство для каждой строки, я не был уверен в этом. – user1314836

+0

Очевидно, что VARCHAR (MAX) не работает в MySQL. Должен ли я использовать VARCHAR (65535) вместо этого? – user1314836

+0

@ user1314836 Извините, я принимал MSSQL. 500 просто казался немного маленьким для «свободного текста». Вы правы - varchar использует только столько места, сколько ему нужно. –

1

Вы, кажется, делаете это в MySQL.

Я заметил, что ваши темы имеют иерархическую структуру. В MySQL довольно сложно управлять такими иерархиями, но, тем не менее, это часто случается. Предполагая, что темы не меняются очень часто, я бы рекомендовал включить «тему» ​​в качестве столбца. Например, если есть темы:

topic1 --> topic11 --> topic111 

Тогда путь будет чем-то вроде темы «topic1/topic11/topic111». Обратите внимание, что это денормализуется, причем одни и те же данные (темы) повторяются в разных строках. Он работает, если темы и иерархии не обновляются (вставки в порядке).

Некоторые дополнительные предложения. Когда столбец ссылается на столбец id, добавьте Id на имя. Итак: ParentTopicId вместо ParentTopic; QuoteId вместо Quote и TopicId вместо Topic. Это особенно важно для ваших данных. Когда два столбца имеют одинаковое имя в разных таблицах, они должны быть, по крайней мере, одинаковыми. Однако Topic - это текстовая форма темы в одной таблице, но идентификатор темы в другой.

Я был бы склонен включать первичный ключ в QuoteTopic под названием QuoteTopicId. Это было бы полезно, например, если эта таблица ссылалась на другую таблицу.

И, я подозреваю, что в вашей структуре данных отсутствует весь размер автора. Цитата интересна из-за того, кто это сказал.

Наконец, в большинстве таблиц я хотел бы включить столбцы CreatedBy и CreatedAt как авторизованные столбцы. В MySQL CreatedAt достаточно легко добавить с помощью метки времени. К сожалению, для CreatedBy потребуется триггер, который является излишним.

+0

Это MySQL, извините, не упомянув об этом. Я не понимаю, почему управление иерархией, как я предлагаю, я бросаю вызов. Я создам страницу, показывающую все кавычки с «верхней» темой (это тема без родительской темы) и показывая все подтемы, чей отец - это один). Ничего другого, я считаю, что это легко сделать с PHP MySQL. Все остальные предложения великолепны. Спасибо огромное! – user1314836

+0

@ пользователь1314836. , , Просто подождите, пока вы не захотите перечислить все темы под определенной темой. Или вы хотите найти все темы на глубине 4. Или определить, существуют ли циклы в вашей иерархии тем. MySQL не поддерживает рекурсивные CTE, поэтому такие запросы сложнее, чем они должны быть. –

Смежные вопросы