Вопросы Теги

Как разработать базу данных фильма?

Я бы даже не стал заморозить элементы (если я правильно понимаю, что вы собираетесь делать). Скорее создайте функцию, которая клонирует N рядов строк вместе с заголовком и расположите их абсолютно поверх оригиналов. Возможно, при необходимости добавьте фильтр невидимости на оригиналы.

РЕДАКТИРОВАТЬ:

Я снова смотрел на код. Вы можете получить некоторое повышение производительности, переместив столько же, сколько общие атрибуты за пределы цикла jquery. Примерно так: 

$.fn.newFreeze = function(num) {
  var left = 0;
  for (var i = 1; i < num + 1; i++) {
    left += i === 1 ? 0 : $(`th:nth-child(${i - 1})`).outerWidth();
    $(`th:nth-child(${i}),td:nth-child(${i})`).each(function() {
      $(this).css({
        left,
        zIndex: 4,
      })
    })
  }
}

th, td {
  position: sticky;
  position: -webkit-sticky;
}
21
задан Robert Gowland 25 September 2012 в 17:36
поделиться

9 ответов

Необходимо сделать различие между атрибутами и объектами. Объект является вещью - обычно существительное. Атрибут больше похож на часть описания информации. На жаргоне базы данных, объект = таблица, атрибут = поле/столбец.

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

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

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

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

Используя суррогатный ключ (первичный ключ) для таблиц обычно хорошая идея. Соответствие целому числу намного быстрее, чем соответствие строке. Это также позволяет Вам свободно менять имя, не вызывая беспокойство о внешних ключах, сохраненных в других таблицах (идентификатор остается таким же, таким образом, Вы ничего не должны делать).

<час>

можно действительно взять этот дизайн довольно далеко, и это - весь вопрос выяснения, что Вы хотите смочь сохранить в нем.

, Например, вместо того, чтобы иметь единственного директора на фильм, некоторые фильмы имеют несколько директоров.. таким образом, были бы many-many отношения между фильмами и директорами, таким образом, Вам будет нужна таблица с, например: 

films_directors => **filmid, directorid**

Взятие его шаг вперед, иногда директора являются также агентами, и наоборот. Так, а даже не имеют директора и таблицы агента, Вы могли иметь единственную таблицу человека и присоединиться к той таблице в использовании ролевой таблицы. Ролевая таблица заняла бы различные позиции - например, директор, производитель, звезда, дополнительная, власть, редактор.. и это посмотрело бы больше как: 

films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**

у Вас могло бы также быть role_details поле в film_people таблице, которая могла содержать дополнительную информацию в зависимости от роли (например, название роли, которую агент играет).

я также показываю жанр many<> многие отношения, потому что возможный фильм находится в нескольких жанрах. Если бы Вы не хотели это, то вместо film_genre таблицы, фильмы просто содержали бы genreid.

, После того как это настраивается, легко запросить и найти все, что данный человек сделал, или все, что человек сделал как директор или все, кто когда-либо снимал фильм или всех людей, связанных с одним определенным фильмом.. Это может продолжиться и на.

60
ответ дан gregmac 29 November 2019 в 06:08
поделиться

То, что следует, не является фактическим кодом MySQL. Походит на то, в чем Вы нуждаетесь, больше концептуального запуска здесь. Таким образом, вот модель того, на что должна быть похожей Ваша база данных.

идентификатор таблицы

  • Actor (первичный ключ)
  • имя
  • фамилия
  • и т.д. (любые дополнительные столбцы Вы хотите сохранить на агенте)

идентификационное
  • имя таблицы

      • директора
    • фамилия
    • и т.д.

    идентификационное
  • название таблицы

      • Genre
    • и т.д.

    идентификационное
  • время выполнения описания
  • заголовка
    • таблицы

      Film
    • дата выпуска
    • идентификатор директора - это - внешний ключ, который обращается к идентификатору (первичный ключ) директора, который направил идентификатор жанра фильма
    • - как идентификатор директора, это обращается к идентификатору жанра, фильм принадлежит [1 122]

    пленочный Агентом индексный идентификатор фильма таблицы

    • - это - внешний ключ, который обращается к идентификатору идентификатора агента фильма
    • - это - внешний ключ, который обращается к идентификатору одного агента в фильме.

    Для каждого агента в фильме, Вы добавили бы строку к Пленочному Агентом Индексу. Так, если агенты 5 и 13 (первичные ключи для тех агентов) соединенный звездой в фильме 4 (снова, первичный ключ для того фильма), у Вас было бы две строки, отражающие что факт в Вашем индексе: Один с пленочным идентификатором = 4 и идентификатором агента = 5, и другой с пленочным идентификатором = 4 и идентификатором агента = 13.

    Hope, которая помогает.

    кроме того, это предполагает, что каждый фильм имеет точно одного директора. Если бы какой-либо фильм в Вашей библиотеке имеет двух директоров (таких как Миллионер из трущоб), Вы хотели бы выделить идентификатор директора от пленочной таблицы и создать Пленочный Директором индекс как Пленочный Агентом Индекс как выше.

    20
    ответ дан Matt Howell 29 November 2019 в 06:08
    поделиться

    Это таблицы, которые я использовал бы: 

    films (_id_, title, runningtime, description)
genres (_id_, name)
people (_id_, name, birthdate, etc...)
roles (_roleid_, rolename)
filmgenres (_filmid_, _genreid_)
castandcrew (_filmid_, _roleid_, _personid_)

    Вместо того, чтобы иметь директоров и таблицу агентов, просто имейте одну таблицу людей. Это может также включать членов команды (в случае, если Вы хотите отследить, кем 2-й Младший помощник Dolly Grip была). Каждый фильм может быть любым количеством жанров (комедия и ужас, например). Плюс, люди могут взять любое количество ролей на каждом фильме - существует множество агента/директоров там.

    таблица Roles не обязательно означает символ, который играет агент, но это могло. Это мог быть "директор", "Производитель", "Агент"... или даже "Luke Skywalker", если бы Вы хотели получить точно гранулировавший... Я полагаю, что IMDb делает это.

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

    11
    ответ дан nickf 29 November 2019 в 06:08
    поделиться

    Вашей таблице Films также нужны ссылки на жанр, директора и таблицы агентов. Начиная с агентов, по крайней мере, будут многие многим (один фильм перечислит больше чем одного агента, один агент будет больше чем в одном фильме), Вам будет нужна таблица для соединения их. 

    Films Table => filmid, filmtitle, runningtime, description, genreid, directorid
Genre Table => genreid, genre
Director Table => directorid, director
Actors Table => actorid,actor_name
FilmActor link table => actorid, filmid (with a record linking each actor to each film)

    Любая таблица, которая могла бы быть многими ко многим потребностям связывающая таблица.

    4
    ответ дан thursdaysgeek 29 November 2019 в 06:08
    поделиться

    я создал уникальный идентификатор для Таблицы Фильмов с первичным ключом, который автоматически увеличивает, я должен создать уникальный идентификатор для каждой таблицы?

    Да, каждая таблица должна иметь уникальный идентификатор. Но, это - не обязательно основной автоматический ключ постепенного увеличения - это - то, что делает тот конкретный экземпляр уникальным. Например, для фильмов, я думаю, что распространено быть заголовком + год выпуска - хотя Вы хотели бы согласовать с любителем фильма (специалист по проблемной области), чтобы быть уверенными в этом. Автоматический инкремент является нейтрализацией - в основном, когда у Вас действительно нет ничего больше к uniqueify на.

    можно использовать автоматический инкрементный ключ для простоты использования в соединениях и таком, но у Вас должно быть ограничение на уникальность данных на поля уникальности так или иначе.

    Что касается фактического дизайна, я предложил бы что-то как: 

    Films => Primary Key(filmid), Unique Constraint(filmtitle, year), 
         runningtime, description, 
         Foreign Key(Genre), Foreign Key(DirectorId)

Genre Table => Primary Key(Genre)

Director Table => Primary Key(DirectorId), DirectorName

Actors Table => Primary Key(ActorId), ActorName

Films_Actors => Primary Key(Foreign Key(ActorId), Foreign Key(FilmId))

    Для вставки, хорошо - откровенно говоря, это - ЛАВАШ. Необходимо вставить в обратном порядке (и это - то, где автоматическими инкрементными ключами может быть еще больший ЛАВАШ - если можно добавить дату рождения или что-то в таблицу Агентов и директоров, затем ограничение на уникальность данных может помочь).

    Так, Вы вставили бы Агента (агентов), директора, Фильм и затем Films_Actors. Идеально, все в единственной транзакции. Кроме того, я предполагаю, что Жанр уже заполнен в и является списком выборки - таким образом, он не должен быть вставлен.

    3
    ответ дан Mark Brackett 29 November 2019 в 06:08
    поделиться

    Я понимаю, что на Ваш вопрос уже ответили, однако я хотел указать на Вас на:
    http://www.imdb.com/interfaces

    IMDb обеспечивает плоские текстовые файлы их базы данных (минус первичные ключи). Вы могли бы найти это полезным для заполнения базы данных, после того как Вы начинаете, или Вы могли использовать ее в своей программе/веб-сайте для разрешения, Вы для простого поиска заголовка фильмов, чтобы добавить к "Набору DVD" и иметь остальную часть информации вытянули от них.

    2
    ответ дан mmcdole 29 November 2019 в 06:08
    поделиться

    Иногда агенты являются директорами и наоборот, возможно, Вы хотите "людей" таблица?

    2
    ответ дан leancz 29 November 2019 в 06:08
    поделиться

    Вам действительно не нужны YearTable и все, в чем Вы нуждаетесь, genre_id, director_id, и actor_id столбцы в Вашей таблице фильмов.

    кроме того, Вашему жанру, директору и таблицам агента нужны их собственные уникальные идентификаторы.

    Редактирование: Это, конечно, предполагает, что Вы только собираетесь иметь 1 жанр, директора, и агент для каждого фильма. Который, вероятно, не имеет место.

    , Чтобы иметь много агентов, принадлежащих многим фильмам, Вам будет нужна отдельная таблица отношений. Вы могли назвать это, "moviesActors" (или actorsMovies) и каждая строка будет иметь actor_id и movie_id для высказывания , этот агент был в этот фильм .

    1
    ответ дан Dean Rather 29 November 2019 в 06:08
    поделиться

    Каждая таблица должна иметь первичный ключ, который уникален.

    Вы должны чтение на нормализация базы данных .

    таблица года А является, вероятно, ненужной.

    , Если это - год выпуска, скажем, затем, год может быть сохранен в фильме.

    , Если бы существует несколько директоров на фильме, то у Вас была бы отдельная таблица, которая удержит первичную клавишу пленочной таблицы и таблицы директора. Так же для любого из ограничений внешнего ключа, которые являются many-one или many-many. В частности, я полагаю, что это относилось бы к Агенту.

    0
    ответ дан Cade Roux 29 November 2019 в 06:08
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: