| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > Хранение связанных данных |
| Автор: WolfAlone 24.2.2011, 15:09 |
| Доброго времени суток! Возникла необходимость сохранить данные в БД. Данные имеют примерно такой формат: Товар: Сапоги замшевые, модель: АБВ-123 Дополнительные данные, включают себя соотношение: размер = цена (например, размер 38 = 500руб., размер 41 = 550руб.) Соответственно, товаров будет более одного и к каждому из них существует таблица с соотношениями размер = цена. Скажите пожалуйста, как лучше организовать хранение такой информации в БД? (Я имею в виду архитектуру БД) P.S. Сервер: MySQL-5. Добавлено через 4 минуты и 19 секунд Чуть не забыл! Модель у каждого товара является уникальным значением. |
| Автор: Zloxa 24.2.2011, 15:15 |
| для описанного Вами случая достаточно одной таблицы. |
| Автор: WolfAlone 24.2.2011, 15:18 | ||
| Если немного дополнить вопрос, то звучать он будет примерно так: "Как организовать хранение и выборку вышеуказанных данных в БД?" Добавлено через 5 минут и 55 секунд
Вы не могли бы привести пример такой таблицы? (я имею в виду её структуру) |
| Автор: Zloxa 24.2.2011, 15:26 |
| Ответ на Ваш вопрос столь элементарен, что не хочется Вас им оскорблять, переводя беседу в русло "как с дебилом". Расскажите лучше как Вы пытаетесь делать, что у Вас не получается и чего Вы опасаетесь. |
| Автор: Akella 24.2.2011, 15:35 |
| Создаёшь таблицу. А потом с помощью запросов оперируешь данными. |
| Автор: WolfAlone 24.2.2011, 15:36 |
| В данный момент в прототипе существует два варианта хранения таких данных. Вариант 1 (в одну таблицу). Пример: Модель / Название / Размер / Цена АБВ-1 / Сапог 1/ 40 / 500 АБВ-1 / Сапог 1/ 42 / 510 АБВ-2 / Сапог 2/ 45 / 490 (и т.д.) Вариант 2 (в две таблицы). Пример: Таблица 1: Модель / Название ID(1) / АБВ-1 / Сапог 1 Таблица 2: Родительский_ID / Размер / Цена 1 / 40 / 500 В варианте 1 происходит дублирование данных и смысл самой БД частично теряется, т.к. все эти данные можно с таким же успехом хранить в текстовом файле (я имею в виду, что никакая обработка данных по сути не требуется, только чтение однородного набора данных). Хотелось бы услышать Ваши комментарии по поводу обоих вариантов. В случае варианта 2 - как лучше производить выборку? Через JOIN? P.S. Всё желательно уместить в рамках одного запроса. |
| Автор: Zloxa 24.2.2011, 15:38 | ||
Если можно это делать с тем же успехом, то что заставляет Вас задуматься о необходимости столь существенного уложнения архитектуры решения? |
| Автор: WolfAlone 24.2.2011, 15:42 | ||
Мысль о том, что правильный выбор архитектуры приложения позволит производить его масштабирование в будущем, без необходимости переписывания большей части кода. |
| Автор: Zloxa 24.2.2011, 15:42 | ||
Первый вариант - пример денормализованного хранения данных. Производительность запросов к такой структуре будет весьма высока, однако для обеспечения согласованности хранимых в таком виде данных, придется изрядно попотеть. Второй вариант - пример нормализованного хранения данных. Запросы к нормализованным структурам куда сложнее и куда менее производительны, однако такой подход позволяет существенно упростить контроль целостности. На практике используются оба подхода |
| Автор: WolfAlone 24.2.2011, 16:05 |
| Благодарю за внимание. Вопрос закрыт. |
