2010-02-19 2 views
1

Итак, вчера я задал два вопроса, которые вращались вокруг одной и той же идеи: реорганизация базы данных, в которой A- не была нормализована, а B- был беспорядок в силу моего невежества. Я провел большую часть дня, организовав свои мысли, прочитав и проработав несколько тестов. Сегодня я думаю, что у меня есть намного лучшее представление о том, как моя БД должна выглядеть и действовать, но я хотел убедиться, что я понял основные идеи правильного проектирования и нормализации SQL DB.Является ли эта структура базы данных правильной и правильной?

Первоначально у меня была одна таблица под названием «Файлы», в которой хранились данные о файле (это URL-адрес, дата загрузки, идентификатор пользователя, кто его загрузил и т. Д.), А также столбец под названием «оценки», который представлял уровень оценки, который вы может использовать этот файл для. (FYI: Эти файлы - планы уроков для школ). Я понял, что нарушил правило № 1 о нормализации. Я хранили свои «оценки», такие как «1,2» или «2,6» или «3,5,6 "в одной колонке. Это вызвало серьезные головные боли при попытке проанализировать эти данные, если я хотел увидеть JUST 3-й класс или только 5-ые уроки.

Что было предложено мне, и то, что стало очевидным позже, было то, что у меня есть 3 таблицы:.

файлы (данные о файлах, URL и т.д.) классов (таблицы доступных уровней класса Вероятно 1 -6) files_grades (соединительная таблица)

Это имеет смысл. Я просто хочу убедиться, что понимаю, что я делаю, прежде чем я это сделаю. Предположим, пользователь A загружает файл xyz и решает, что он подходит для классов 2 и 3.

Я бы записал одну запись в таблицу «файлы» с данными об этом файле (размер, URL, URL, описание, имя, первичный key files_id). Скажем, он получает идентификатор 345.

Из-за ограниченного числа вариантов классов, классов, вероятно, будет эквивалентно идентификатору (т.е. класс 1 является grades_id 1, Grade 2 является grades_id 2)

Я бы затем записать две записи в "files_grade" распределительной таблицы, содержащей

files_grade_id, files_id и grades_id т.е.

1,345,2

1,345,3

Чтобы представить 2 класса, для которых подходит file_id 345. Затем я размахиваю волшебными клавишами SELECT и JOIN и извлекаю нужные данные.

Имеет ли это смысл? Повторяю ли я неправильное представление о правильной структуре реляционной базы данных «многие ко многим»?

Задача 2, которая только что рассвела на меня: Итак, урок может иметь несколько «классов». Нет проблем, мы просто решили это (надеюсь!). Но теоретически он мог бы иметь множество «Школ» - Элементарный, Средний, Высокий. Что мы будем делать, если запись файлов имеет классы 1,2 для среднего, высокого? Это можно было бы легко решить, сказав «Одна школа за файл, пользователи!», Но мне нравится бросать это там.

ответ

0

Из звуков этого звука это звучит неплохо. Только одно: вам действительно не нужно иметь идентификатор таблицы моста (FILES_GRADES), и если вы это делаете, вам нужно увеличить его.

У вас должен быть первичный ключ из двух частей: grade_id и file_id, файлы_файлы_файла просто усложняют ситуацию и делают для плохого индекса, так как вы никогда не будете использовать его в select.

+0

Ah. В этом есть смысл! Спасибо. – GilloD

1

Я тогда написал две записи в "files_grade" соединения таблицы, содержащей

files_grade_id, files_id и grades_id т.е.

files_grade_id здесь является излишним, поскольку сочетание files_id и grades_id уже уникален (поэтому может быть установлен как первичный ключ).

Но теоретически он может иметь несколько «Школ», а также - Элементарный, Средний, Высокий. Что мы будем делать, если запись файлов имеет классы 1,2 для среднего, высокого?

В зависимости от вашего требования вы можете сохранить их как «продолжения» предыдущих оценок, например. 1-6 элементарных, 7-9 средних, 10-12 высоких. Тогда вы можете обойтись без таблицы полностью (поскольку вы можете просто сохранить эти цифры в таблице files_grade).

+0

Вот головная боль: Это предназначено для корейских школ, которые являются К-6. Затем средний 1-2 и высокий 1-4. BLEH. Новая идея: В точке захвата , если школа = старшая школа и класс = 2, класс = 10 или что-то еще. Мне нужно подумать об этом немного. Я могу просто придерживаться одноклассной вещи. – GilloD

0

С первого взгляда на этот вопрос уже был дан ответ Я возьму удар по второму.

Существует несколько способов сделать это, но одна из возможностей - добавить еще одну таблицу для «Школ» и включить ее как часть соединительной таблицы - переименование таблицы переходов, конечно, в соответствии с новым дизайном. Таким образом, вы могли бы:

School Table: 

------------------------- 
    SchoolId | School 
------------------------- 
    1  | Elementary 
    2  | Middle 
    3  | High 
------------------------- 

Files_grades_school 

------------------------------------ 
    FileId | GradeId | SchoolId 
------------------------------------ 
    345 |  1  |  1 
    345 |  1  |  2 

Возможно, вы захотите создать несколько индексов на основе шаблонов использования.

+0

Проблема заключалась в том, что могут быть МНОЖЕСТВЕННЫЕ идентификаторы школы. Думаю, пока я ограничусь. Честно говоря, они все равно умны, различие состоит в том, что начальные уроки адаптированы к учебной программе, где средний/высокий - свободная форма. – GilloD

+0

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

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