Это похоже на правильный дизайн базы данных?

-1

Я проработал несколько недель, пытаясь прочитать обо всех разработках надлежащей структуры базы данных. После многих попыток, я думаю, у меня может быть то, что считается правильным. Но я скептически отношусь к тому, правильно ли я соединяю таблицы и внешние ключи. База данных, над которой я работаю, состоит из нескольких взаимосвязей, связанных с песней song_title. Связанное изображение - это то, что у меня есть в настоящее время. Правильно ли это выглядит?Это похоже на правильный дизайн базы данных?

Каждая песня может иметь много цветов.

Один цвет может иметь только один набор значений.

Каждое значение цвета имеет только один набор значений dmx.

Каждое значение цвета имеет только один набор процентных значений.

Каждая песня может иметь только одно настроение.

Каждое настроение может применяться к нескольким композициям.

Каждая песня может иметь только одно значение времени_сигнала.

Каждый раз_сигнал может применяться к нескольким композициям.

Каждая песня может иметь только одну компоновку.

Каждая схема может применяться к нескольким композициям.

Каждая песня может иметь только один темп.

Каждый темп может применяться к нескольким композициям.

В каждой песне может быть только один fire_cue.

Каждый fire_cue может применяться к нескольким песням.

Одна песня может содержать несколько mp3-файлов.

Каждый mp3 может принадлежать только одной песне.

Одна песня может содержать несколько файлов img.

Каждый img может принадлежать только одной песне.

enter image description here

источник

2015-01-30 Zach Sisk

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

Святое дерьмо. Вероятно, вы избавитесь хотя бы от 1/3 этих таблиц (может быть, больше). Q: Какая часть «time_signature» (например), * не является внутренним свойством конкретной «песни»? – FoggyDay

time_signature, настроение, расположение, fire_cue и темп - это все таблицы, которые будут иметь заданные значения. Таким образом, темп будет в основном статичной таблицей, которая никогда не изменится, но мне нужен способ определить темп песни. –

Там нет правильно или право способ создать базу данных. То, что у вас здесь, выглядит хорошо продуманным и может быть способом разработки вашей базы данных для ваших нужд. Что еще более важно, чем ответить, если это правильный дизайн базы данных (который кто-то мог дать свое мнение , и все они могли различаться) заключается в том, работает ли база данных для проектирования вашей инфраструктуры.

Планируете ли вы использовать эту базу данных или вы просто возитесь с ERD и дизайном? Если вы собираетесь использовать его, вы можете обнаружить, что ваша сложность может быть слишком высокой. Вы могли бы обнаружить, что отношения, которые вы создали, не должны существовать (как и для целых таблиц или сущностей). Трудно ответить на ваш вопрос, потому что мнения - это все, что вы получите в ответах.Я думаю, что для вас важно начать писать свою программу и писать запросы и вызывать информацию, которую вы сохранили в своей базе данных, чтобы действительно найти, идеально ли ваш дизайн базы данных!

источник

2015-01-30 01:59:59 triforceofcourage

Это то, что я активно пытаюсь работать. Моя неудача заключалась в изучении того, как вещи должны быть организованы внутри базы данных. У моей первоначальной формы была одна таблица с каждым из приведенных выше значений в одной строке. Мне сказали, что это было неэффективно и позволяло место для дубликатов/ошибок, когда я выполняю операции CRUD. Поэтому я посмотрел в нормальные формы, и теперь я пытаюсь понять, правильно ли я сделал. Возможно, вы правы, что я делаю отношения, которые не нужны. Я пытаюсь найти эти недостатки. –

Это похоже на правильный дизайн базы данных?

ответ

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