Блог

Я хотел бы создать базу данных для карт 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.

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

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

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

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

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

 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 очень много деталей (цветной текст, как кто-то упоминал), но они, вероятно, не важны для такого рода моделей, поскольку они предназначены для отслеживания фактических карт ради сбора и продажи. Но если возникнет желание добавить какие-либо другие атрибуты, например, редкость карт, таблица «card» будет подходящим местом для их размещения.

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

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

Есть две простые таблицы поиска, таблица condition и saletype. Эти две таблицы приведены здесь для целей нормализации и позволяют пользователю стандартизировать свои термины для этих двух категорий данных. У каждого из них есть «псевдоним» и «описание». Псевдоним — это короткая английская версия: «Good», «Poor», «Auction», «Buy it now», в то время как описание представляет собой более длинный текст на английском языке: «На плохих картах видны следы износа, изгиба и потертости». Очевидно, что кому-то, кто делает это для своих собственных целей, вероятно, не нужно описание, но оно есть как привычка.

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

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

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

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

Обратите внимание, что на самом деле невозможно обеспечить, чтобы карта была членом КАКОГО-ЛИБО набора или чтобы в наборе были какие-либо карты. Это будет проблемой логики приложения. Это одна из проблем, связанных со столярными таблицами «многие ко многим». Он может моделировать отношения, но не может применять их.

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

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

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

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

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

Я предлагаю вам взглянуть на файл данных из www.mtgjson.com

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

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