Магия: сбор данных дизайн базы данных

Question

Я хотел бы создать базу данных для карт MTG, которыми я владею. Каким будет дизайн? Я хотел бы хранить следующую информацию о каждой карточке:

1. Name of card.
2. Set the card belongs to.
3. Condition of card.
4. Price it sold for.
5. Price I bought it for.

Вот небольшая информация о картах MTG в целом:

1. Every card has a name. 
2. Every card belongs to a set.
3. A card may have a foil version of itself. 
4. Card name, set it belongs to, and whether it's foil or not makes it unique. 
5. A card may be in multiple sets.
6. A set has multiple cards. 

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

У меня будет другая коллекция карт MTG, которые были проданы на eBay. Эта коллекция будет иметь цену / условие / дату / была ли она "Купить сейчас" или ставку и т. Д.

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

Answer 1

Это не вопрос программирования, это вопрос моделирования. Любой, кто программирует, но не моделирует, является программистом, а не программистом. Это всего лишь шаг над вводом данных. Моделирование является фундаментальным аспектом программирования, так как оно имеет дело непосредственно с абстракцией, а абстракция является настоящим гением компьютерного программирования.

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

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

Например, аргументы на совещаниях разработчиков не связаны с синтаксисом языка.

Итак, что сказал. Я обновил схему незначительными способами, чтобы учесть изменения.

create table card (
    card_key numeric not null primary key,
    name varchar(256) not null,
    foil varchar(1) not null); -- "Y" if it's foil, "N" if it is not.

create table set (
    set_key numeric not null primary key,
    name varchar(256) not null);

create table cardset (
    card_key numeric not null references card(card_key),
    set_key numeric not null references set(set_key));

create table condition (
    condition_key numeric not null primary key,
    alias varchar(64),
    description varchar(256));

create table saletype (
    saletype_key numeric not null primary key,
    alias varchar(64),
    description varchar(256));

create table singlecard (
    singlecard_key numeric not null primary key,
    card_key numeric not null references card(card_key),
    condition_key numeric not  null references condition(condition_key),
    purchase_date date,
    purchase_price numeric,
    saletype_key numeric references saletype(saletype_key),
    sell_date date,
    sell_price numeric,
    notes varchar(4000));

Более подробное объяснение.

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

Набор столов для наборов. Я не знаю, что такое набор, только то, что здесь указано (есть также случайная ссылка на серию, я не знаю, связаны ли они или нет). Наборы имеют имя и используются для группировки карт. Итак, у нас есть таблица "set".

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

Существует две простые таблицы поиска: таблица условий и продаж. Эти две таблицы приведены здесь для целей нормализации и позволяют пользователю стандартизировать свои термины для этих двух категорий данных. У каждого из них есть "псевдоним" и "описание". Псевдоним - это короткая английская версия: "Хорошо", "Плохо", "Аукцион", "Купи сейчас", а описание - более длинный текст на английском языке "Плохие карты показывают следы износа, изгиба и потертостей". Очевидно, что кто-то, делающий это для своих собственных целей, скорее всего, не нуждается в описании, но это как привычка.

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

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

Исходя из того, что было дано, это должно отвечать основным потребностям.

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

Обратите внимание, что на самом деле нет способа принудительно установить, что карта является членом ЛЮБОГО набора, или что в наборе есть какие-либо карты. Это будет проблемой логики приложения. Это одна из проблем, возникающих при использовании столов "многие ко многим". Он может моделировать отношения, но не может обеспечить их соблюдение.

Answer 2

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

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

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

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

Я бы прочитал "Реляционные базы данных". Если вы действительно потерялись, я предлагаю взять копию "SQL для чайников", SQL - это язык, который использует большинство поставщиков баз данных, и у него есть пошаговые инструкции и учебные пособия для создания ваших собственных баз данных ".

Answer 3

Я предлагаю вам посмотреть файл данных с www.mtgjson.com

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

Например, вы увидите, как они обрабатывают повторяющиеся имена, карты, которые связаны друг с другом, как одна перевернутая или повернутая или объединенная версия другой, и еще много мелких нюансов.