Спасибо. Буду пробовать. Буду смотреть на скорость реагирования. Если система начнет зависать, буду облегчать, вплоть до статики.продолжение мыслей про объективы.
Естественно.а ведь еще надо, наверное, внести как отдельную сущность "макро-объективы".
Понятно. Впишется это в готовую систему, так же будем смотреть.phis писал(а): Мне видится это так:
Сущности:
1) "Object" - какой-либо объект: объектив, камера, аксессуар и т.п.;
2) "Category" - категория, например: "Фокусировка";
3) "Type" - тип, например (применительно к п.2), "Авто" или "Ручная".
Таблица Catalogue - связь между объектами (например, камерой) и их типами (например, "электронный затвор"). Тип связи "многие-ко-многим", т.е. один объект может обладать набором типов, либо один тип может быть у многих объектов.
Поле "Name" у таблиц - наименования. Например, "AF Micro-Nikkor 200mm f / 4D IF-ED" для Object.
"*_id" - идентификаторы записей.
Ага, это ты так отпуск проводишь ?Уже третий день строю таблицы. Крыша едет. Кто-то подскажет?
Зачем такая сложная структура ? Любая база SQL позволяет все это свести в три таблицы.phis писал(а): Мне видится это так:
Сущности:
1) "Object" - какой-либо объект: объектив, камера, аксессуар и т.п.;
2) "Category" - категория, например: "Фокусировка";
3) "Type" - тип, например (применительно к п.2), "Авто" или "Ручная".
Таблица Catalogue - связь между объектами (например, камерой) и их типами (например, "электронный затвор"). Тип связи "многие-ко-многим", т.е. один объект может обладать набором типов, либо один тип может быть у многих объектов.
Поле "Name" у таблиц - наименования. Например, "AF Micro-Nikkor 200mm f / 4D IF-ED" для Object.
"*_id" - идентификаторы записей.
Sandro писал(а): ...
Зачем такая сложная структура ? Любая база SQL позволяет все это свести в три таблицы.
Таблица "Объективы", где каждое классифицируемое свойство объектива хранится в виде перечислимого значения соответствующей колонки (например, тип объектива - "Широкоугольник" или "Нормальный" или "Телевик"). Если объектив может при этом обладать несколькими значениями одного свойства, то для этого есть тип данных "SET".
Аналогично - таблица "Камеры"
И, наконец, таблица совместимости, представляющая собой реляционную таблицу "Камеры - объективы", где обязательно помимо колонок-ссылок (индексов) таблиц "Камеры" и "Объективы" должны быть колонки, в которых отмечается поддержка тех или иных свойств (например, поддержка экспозамера или его отсутствие в данной комбинации камера-объектив.
...
Вы просто предлагаете построить объектно-ориентированную базу. Это я понял. Но в данном случае в этом нет никакой необходимости. Все прекрасно решается с помощью реляционной БД (которая так же может восприниматься и как ОО). Просто у нас разный подход в реализации. Вы предлагаете хранить все объекты (экземпляры классов) в одной куче (таблице), а их свойства - в другой. Правда, Вам без реляционной таблицы все равно не обойтись - надо же, например, как-то показать, с какими камерами какие объективы совместимы, с какими камерами будет работать 3д экспозамер и т.д. Т.е. одну табличку Вам все равно придется добавлять.phis писал(а): Любой объектив или камера могут обладать какими-либо свойствами (характеристиками). Например, AF 50 1.4: фокусировка = автофокус, тип = фикс, угол поля зрения (?) = нормальный и т.п. то же и для камер и для любых аксессуаров, поэтому я и предложил хранить объекты (камеры, объективы, аксессуары) в одной куче (таблице Objects), а с помощью остальных таблиц обеспечить соответствие заданным характеристикам.
На самом деле структура крайне проста и в рамках поставленной задачи очень даже масштабируема (если в дальнейшем придется классифицировать другие сущности, например, фильтры или вспышки, - не придется добавлять дополнительных таблиц в базу).
Все это ИМХО.
P.S.Может быть я Вас не совсем правильно понял, - черканите схему, чтобы было яснее.
Sandro писал(а): Вы просто предлагаете построить объектно-ориентированную базу. Это я понял. Но в данном случае в этом нет никакой необходимости. Все прекрасно решается с помощью реляционной БД (которая так же может восприниматься и как ОО). Просто у нас разный подход в реализации. Вы предлагаете хранить все объекты (экземпляры классов) в одной куче (таблице), а их свойства - в другой. Правда, Вам без реляционной таблицы все равно не обойтись - надо же, например, как-то показать, с какими камерами какие объективы совместимы, с какими камерами будет работать 3д экспозамер и т.д. Т.е. одну табличку Вам все равно придется добавлять.
У меня каждый класс представлен отдельной табличкой, каждая строка которой соответствует одному экземпляру класса (объекту), а каждый столбец - одному свойству. Как показывает мой опыт разработок, такой вариант более логически понятен для других и позволяет делать большинство выборок по одному классу объектов, обращаясь только к одной таблице.
Ваш вариант удобен в том случае, когда свойства объекта сильно разрежены или представляют собой массивы переменной длины - в этом случае существенно экономится дисковая память, но замедляются выборки при больших таблицах или больших списках свойств.
Схемку нарисовать сейчас не могу - нет под рукой соответствующего инструментария. Но думаю, Вы и так все поймете.
А когда еще занимается? Но я много не успел. Надо еще неделю брать. Благо она есть. Но отпустят?Ага, это ты так отпуск проводишь ?
Дело в том, что любой движок делает свои таблицы. Не один не позволяет работать с произвольными данными.Не знаю, какой движок выбрал Филипп, но исходя их общих соображений и опыта работы с различными видами SQL БД считаю данный подход наиболее оптимальным. Тем более, что при необходимости в таблицы "Камеры", "Объективы" и т.д. можно вводить новые колонки свойств, вводя дополнительное категорирование и не нарушая при этом старое.
Что ускорить работу, уменьшив число запросов к базе. Ага. И кто этим будет занимается? Я хоть раньше занимался программированием и писал базы данных под заказ, но это было давно. А по основном специальности я фотограф. И хочу фотографировать. Но после того как я занялся форумом, я забыл, что такое фотоаппарат.Как вариант (если будет использоваться MS SQL Server 2005) можно описать собственный тип данных на .NET и хранить его, либо XML.
Philipp (Arkady) писал(а): ...
Ага. И кто этим будет занимается? Я хоть раньше занимался программированием и писал базы данных под заказ, но это было давно. А по основном специальности я фотограф. И хочу фотографировать. Но после того как я занялся форумом, я забыл, что такое фотоаппарат.
Хотя под .NET в Дельфи или ВБ мне писать легче чем в php (на котором я не когда не работал раньше).
, правда много времени обещать не могу... 
Спасибо. Но опасаюсь переходить под Windows. Хотя бы из-за того же форума который работает на PHP. А оно под Windows имеет свои глюки.Ну если ASP.NET, то я могу поучаствовать на добровольных началах
Их уже очень много. Но они солидно дороже. И не уверен, что будет лучше.Недостаток - искать хостера, поддерживающего Windows-хостинг.
Сейчас этот форум просматривают: ClaudeBot [Bot] и 0 гостей