Меню
Что нового?

как структурировать данные в БД?

dimm_mds

Новичок
как структурировать данные в БД?

Здравствуйте!
Необходима Ваша помощь.
Имеется несколько видов оборудования, у каждого из которых есть как свои уникальные характеристики(у одного расход воздуха, у другого расход газа и т.п.), так и одинаковые(вес, габариты, производительность и т.п.)
Как в БД внести для каждого оборудования свои необходимые параметры?

Аппарат 1:

Производительность, кг/час: 1000
Габаритные размеры, мм: 100х100х100
Расход воздуха, м3/ч: 10

Аппарат 2:

Производительность, кг/час: 300
Габаритные размеры, мм: 130х130х120
Расход газа, м3/ч: 5

Аппарат 2:

Производительность, шт/час: 50
Габаритные размеры, мм: 1300х135х1320
Объем бункера, литр: 7

и.т.д
 

Иван 76

Новичок
dimm_mds,
а как ты пробовал, что у тебя получилось, на чем ты остановился, и в чем заключается твоя проблема?

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

Если не участвуют - то можно просто serialize() и хранить все в поле-свалке, например под названием data или properties.

Если они участвуют в процессе формирования выборки, то вариантов несколько:
1. Храни каждый тип объекта (под типом объекта в этом контексте понимается тип оборудования с одинаковым набором параметров) в разных таблицах (самый примитивный вариант).
2. Сваливай в таблицу-свалку те поля, которые не есть общими для всех типов объектов (смотри как устроен модуль profile в CMS Drupal www.drupal.org ).
3. Тоже, что и вариант 2, но с разделением на тип данных (целочисленное, строка и пр.). Пример реализации смотри как устроен модуль catalogue в системе http://mzz.ru/ . В отличии от варианта 2, это устраняет проблему избыточности (при хранении чисел) и позволяет использовать индексы (так как в варианте 2 мы вынуждены хранить все данные в поле с типом text - longtext, или в бинарных полях)
4. Делай объектно-ориентированное хранение данных. Пример реализации смотри в модуле CCK для Drupal или смотри как устроено основное хранилище объектов в CMS eZpublish www.ez.no
 

dimm_mds

Новичок
А что, если сделать так:
В под каждое оборудование сделать поле Properties, в котором будет записть типа:
{1} [100] {3} [23] {4} [399]... тоесть {} - в таких скобках ID параметра, в [] - значение
Так же имеется таблица с назавниями всех параметров, у каждого из которых свой ID.

Далее, при формировании странички с характеристиками, считываем поле Properties, парсим его и с него достаем ID параметра и значение. Далее по ID ищем название параметра.
Как такой вариант?

-~{}~ 21.11.08 11:41:

Ну, люди, ответте пж....
 

Иван 76

Новичок
Да, я говорил об этом. Так можно делать. Но ты не сможешь вывести СПИСОК оборудования, у которого Расход воздуха от 5 до 10, м3/ч.
Точнее, - не сможешь этого делать средствами БД, а только средствами PHP, со всеми вытекающими последствиями.

-~{}~ 21.11.08 19:05:

Совет. Не парься. Возьми Drupal + CCK + Views или mzz.ru

-~{}~ 21.11.08 19:08:

Еще мне хвалили http://www.magentocommerce.com/ , но я туда еще не вникал.
Я по интернет-магазинам не спец, больше работаю с портальными системами.
Покопайся еще на http://hotscripts.com/ , подобные задачи часто решаются для интернет-магазинов.
 

dimm_mds

Новичок
Большое спасибо, Иван 76!
Сайт не большой и будет всего порядка 20 видов оборудования, поэтому не хочется заморачиваться со сторонними CMS. Выборки по тех характеристиках, типа производительность от..до.. не будет.
 

Иван 76

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

-~{}~ 21.11.08 19:31:

Друпал - довольно неплохая система.
Для большинства задач - очень хорошее решение. И очень популярное решение в США.
На Drupal сделаны такие известные и авторитетные сайты в мире программирования, как:
http://www.ubuntu.com/
http://www.jquery.com/
http://dojotoolkit.org/


Но есть моменты, по которым я лично ее не использую.
- В Drupal не используется ООП, а значит нет возможности использовать наследование, переопределять методы.
- В Drupal нет паттерна MVC. Особенно огорчает отсутствие моделей ORM. Это понижает (в совокупности с первым замечанием) повторную используемость кода, что отражается на снижении скорости разработки новых модулей.
- Отсутствие тагетирования кэша. В результате, при добавлении новой Ноды кэш убивается весь. При добавлении нескольких объявлений в минуту, штатная система кэширование не только не снижает нагрузку, но и повышает ее.
- Отсутствие кеширования страниц для авторизованных пользователей. Отсутствие технологии NOCACHE, т.е. в теле кэша невозможно иметь незакэшированный фрагмент.
- Клиентский кеш привязан к времени создания кэша, а не ноды. Т.е., - его просто не существует (можно принебречь), особенно для поисковых систем. Отсуда - рост паразитного трафика, и плохое состояние поискового индекса (т.к. не всегда робот удачно считывает страницу полностью).
- Бестолковая работа с огромными древовидными структурами. Ситуацию поправил разработчик модуля http://drupal.org/project/hierarchical_select , но этот модуль так и остался в рамках версии Drupal5.
- Ограниченный уровень вложенности древовидных структур, вызванный способом хранения Materialized Path.
- На оф.сайте Друпала хоть и говорится про объектно-ориентированное хранение данных, - на практике добиться единого хранилища объектов, как в eZpublish им не удалось. Присутствует три хранилища объектов - ноды, таксономия, комментарии. Т.е. монопольного понятия "класс" не существует (это равносильно, как если бы в PHP были бы несколько способов для работы с классами, в зависимости от назначения класса).

Поэтому я потратил 4 месяца напряженного труда, чтоб написать свою систему на основе Zend Framework. Но я ее разрабатывал под влиянием Друпала.
 

dimm_mds

Новичок
Спасибо Иван 76. Но,:\ ... мне до такого уровня еще далеко... всем тем что ты описал (моменты) я не пользуюсь, PHP начал потихоньку изучать в 2006, потратил пару недель, потом пришлось заниматься другим родом деятельности. Теперь вот опять стала необходимость перевести фирменнй сайт на PHP. Вот и ваяю...
 
Войдите или зарегистрируйтесь для ответа.
Сверху