мнения и рекомендации по структуре базы данных

#mysql #sql #database-design #data-modeling

#mysql #sql #база данных-дизайн #моделирование данных

Вопрос:

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

 a:b:c:d:e
a:b:c:d:e
a:b:c:d:e
a:b:c:d:e
  

И у меня есть список категорий, на которые можно разбить эти строки, например:

 Original   Cat1  Cat2  Cat3  Cat4  Cat5
---------------------------------------
a:b:c:d:e  a     b     c     d     e
  

С этой секунды известны названия категорий, а также количество категорий, по которым нужно разбить данные. Но это может измениться со временем (например, категории добавлены / удалены … общее количество категорий изменено).

Хорошо, на самом деле я не ищу помощи в том, как анализировать строки или получать данные в БД или что-то еще…Я знаю, как все это сделать, и у меня в основном уже написан основной скрипт для обработки синтаксического анализа строк значений и разделения на переменное количество категорий.

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

 Table: Generated
generated_id        int           - unique id for each row generated
generated_timestamp datetime      - timestamp of when row was generated
last_updated        datetime      - timestamp of when row last updated
generated_method    varchar(6)    - method in which row was generated (manual or auto)
original_string     varchar (255) - the original string

Table: Categories
category_id         int           - unique id for category
category_name       varchar(20)   - name of category

Table: Category_Values
category_map_id     int           - unique id for each value (not sure if I actually need this)
category_id         int           - id value to link to table Categories
generated_id        int           - id value to link to table Generated
category_value      varchar (255) - value for the category
  

По сути, идея заключается в том, что когда я разбираю строку, я вставляю новую запись в таблицу Generated , а также X записей в таблице Category_Values , где X — это то, сколько категорий существует в данный момент. А названия категорий хранятся в другой таблице Categories .

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

Похоже ли это на нормальную структуру базы данных? Что-нибудь очевидное, чего я не понимаю или на что потенциально могу повлиять? Например, с этой структурой … хорошо…Я не эксперт по sql, но я думаю, что я должен быть в состоянии сделать как

 select * from Generated where original_string = '$string'
// id is put into $id
  

и затем

 select * from Category_Values where generated_id = '$id'
  

… и тогда у меня будут мои данные для работы с результатами поиска или формой для изменения данных…ну, я вполне уверен, что могу даже объединить это в один запрос с помощью join или чего-то еще, но я не настолько силен в sql, поэтому я не знаю, как на самом деле это сделать .. но суть в том, что я знаю, что могу сделать то, что мне нужно, из этой структуры БД .. но я делаю это сложнее, чем нужно? Совершаете какую-то очевидную ошибку новичка?

Комментарии:

1. добро пожаловать в stackoverflow, очень хороший вопрос, хороший макет и много справочной информации.

2. FWIW: выберите * из Category_Values, где generated_id в (выберите generated_id из Generated, где original_string=’$string’)

3. Спасибо Джереми, запишу это 🙂

Ответ №1:

Мое предложение:

 Table: Generated
id                  unsigned int autoincrement primary key
generated_timestamp timestamp
last_updated        timestamp default '0000-00-00' ON UPDATE CURRENT_TIMESTAMP
generated_method    ENUM('manual','auto')
original_string     varchar (255)

Table: Categories
id                  unsigned int autoincrement primary key
category_name       varchar(20)   

Table: Category_Values
id                  unsigned int autoincrement primary key
category_id         int           
generated_id        int           
category_value      varchar (255) - value for the category
  FOREIGN KEY `fk_cat`(category_id) REFERENCES category.id
  FOREIGN KEY `fk_gen`(generated_id) REFERENCES generated.id
  

Ссылки
Временные метки: http://dev.mysql.com/doc/refman/5.1/en/timestamp.html
Синтаксис создания таблицы:http://dev.mysql.com/doc/refman/5.1/en/create-table.html
Перечисления:http://dev.mysql.com/doc/refman/5.1/en/enum.html

Комментарии:

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

Ответ №2:

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

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

Комментарии:

1. Спасибо 🙂 .. Я действительно не влияю на названия категорий или на то, сколько их будет. Клиент в основном вручную создавал выходные файлы в Excel на протяжении многих лет и нанял меня для автоматизации процесса. Итак, я знаю, основываясь на их истории, что категории не будут часто меняться, но они иногда меняются, потому что бизнес нуждается в изменениях. И в целом, это в основном просто разбивка исходного значения и создание классификаций, так что в основном одни и те же данные просматриваются по-разному, и (повторная) классификация имеет обратную силу, так что это не такое большое значение, когда оно меняется.