MS Excel vs. MS Access.
Передо мной стоит вопрос на базе чего лучше решить одну проблему, поясню ее на упрощенном отвлеченном примере:
Требуется создать форму (или лист в Excel), на которой будет осуществлена возможность выбора обстановки комнаты (шкафы, столы, стулья, диваны, etc…) и их аксессуаров или особенностей. Например, стулья бывают разных видов: маленькие, средние и большие;
Обивка стульев может быть из разных материалов: бархат, ситец, хлопок, etc.;
Цвет у нее тоже может быть разным.
Но существуют ограничения:
- маленькие стулья могут иметь только ситцевую или хлопчатую обивку;
- только большие стулья могут быть с подлокотниками;
- бархат может быть только красным или синим, а ситец – любого цвета;
- и так далее: имеем ограниченное количество наперед заданных ограничений;
Я хочу организовать выбор всех возможных предметов обстановки в качестве отдельных полей со списком; и для каждого отдельного предмета (поля) сделать необходимое количество полей со списком для выбора его аксессуаров или свойств. Но мне нужно, чтобы источники данных для этих списков формировались в зависимости от выбранного предмета с учетом ограничений.
Кроме того, я хочу, чтобы поля имели условия по умолчанию, которые не просто заданы, а рассчитываются по некоторым известным формулам на основании исходных данных, которые пользователь задает вначале.
Например, в большой комнате с окнами по умолчанию расположен большой красный бархатный стул, а в большой комнате без окон – большой синий бархатный стул с подлокотниками.
Посоветуйте, пожалуйста, стоит ли ради решения подобной проблемы вспоминать Access или ее можно решить в VBA + Excel. Мне кажется, что связи-ограничения, о которых я писал выше в Access организовать просто, а в Excel – проблематично. Но в Access, наверняка, полно своих заморочек (каких?).
Заранее спасибо.
В Экселе возможно всё! [...] Независимо от того, на чем ты будешь делать, главное - четко представлять себе задачу. В общем, если будут проблемы с Экселем - поможем. Удачи.
Мне тоже больше нравится Excel, но основная проблема - каким (наиболее оптимальным) образом организовать "ограничения-связи" модификаций предметов интерьера с их аксессуарами.
Положим, что мы имеем наименований предметов - штук 20, каждый из них содержит по 10 - 15 модификаций (типа большой - маленький стул), и каждая можификация предмета имеет свой диапазон возможных значений аксессуара из двух-пяти позиций (аксессуаров две-три штуки на каждый предмет). Уф.
Допускается возможным создать отдельные таблицы всех предметов, всех модификаций предметов, всех аксессуаров.
Требуется создать эти самые связи: для того чтобы ввести ограничения на список допустимых значений аксессуаров для каждой модификации предмета.
Уже реализован вариант создания отдельных списков допустимых значений аксессуаров для каждой модификации предмета. Но это не оптимальный вариант (очень долго все вводить, и потом, в нем сам черт ногу сломит).
Есть ли мысли как можно сделать проще?
1. "Предмет" = Стул, Стол - это я вроде понял.
2. "Модификация" - "Размер", "Цвет" - так?
3. И у каждой модификации есть свой список "Значений модификации" ("большой", "маленький")?
4. Что есть "Аксессуар"?
В общем, разбери по составу предложение "маленькие стулья могут иметь только ситцевую или хлопчатую обивку".
И вообще, что на что намазать - это дело вкуса. Фанаты Эксесса предпочитают все делать на Эксессе. Независимо от того, на чем ты будешь делать, главное - четко представлять себе задачу. В общем, если будут проблемы с Экселем - поможем. Удачи.
А я как раз из этих... из Акесовских...
По мне лучше вбить все ограничения в таблички и делать автоматические выборки из них... Что может быть проще? Плюс интерфейс настраивается лучше некуда (за что особенно Акес и люблю)...
В общем, если будут проблемы с Акесом- поможем. Удачи.
:D
А я как раз из этих... из Акесовских...
По мне лучше вбить все ограничения в таблички и делать автоматические выборки из них... Что может быть проще? Плюс интерфейс настраивается лучше некуда (за что особенно Акес и люблю)...
В общем, если будут проблемы с Акесом- поможем. Удачи.
:D
Вот видишь, как удачно всё складывается. Сейчас ещё подтянутся фанаты Ворда и поклонники ПауэрПойнта, и ты получишь полноценное офисное приложение. Я как вижу себе эту штуку.
В аксессовских формах пользователь выбирает себе маленький стул с ситцевой обивкой и на гусеничном ходу (при этом эта база, как и положено Аксессу поддерживает одновременную работу до 1000 пользователей и до 100...000 наименований), после выбора всего этого в Экселе тут же рисуются накладные и приходные ордера (поскольку Экселю нет равных в плане художественного оформления документов, эти накладные получат Гран-При на выставке товарных документов в Брюсселе-2008 ), в Ворде формируется Договор Поставки, Договор О Намерениях Поставки и Договор О Том Что Будет Если Не Будет Поставки (прекрасным литературным языком, достойным пера Толстого и Достоевского), а в ПауэрПойнте создается презентация, где из левого нижнего угла экрана выезжает маленький стул, с верхнего края ситцевая обивка (со звуком закрывающейся кассы) и из правого нижнего угла появляются гусеницы (с визгом тормозов, естественно). А если еще и в Автокаде три проекции... В общем, Билл Гейтс от зависти продаст свой Майкрософт и купит Усть-Илимскую Мебельную Фабрику, чтобы иметь возможность пользоваться таким софтом.
Ну ладно, это все мечты. Ты там не пропадай, а то из нас уже идеи так и прут... :)
А если еще и в Автокаде три проекции...
Могу в Arcon-е поспособствовать с 3D видом...:D
Могу в Arcon-е поспособствовать с 3D видом...:D
У меня тоже Аркон 4.0 есть. Классная штука. Только немецкий знать надо - неудобно.
У меня тоже Аркон 4.0 есть. Классная штука. Только немецкий знать надо - неудобно.
4-ый уже давно русский есть. 6.0 -вот тот только немецкий...
Sorry за оффтоп....
4-ый уже давно русский есть. 6.0 -вот тот только немецкий...
Sorry за оффтоп....
В той версии, которая у меня, ехешник русифицирован, а названия файлов с текстурами, мебелями и т.п. - сохранены немецкие.
Оффтоп - ничего страшного - здесь все свои, да и модератора у нас нету (оглядывается по сторонам ;-) )
Короче, IKor, не томи людей. Тебе ответят максимум через пару часов. Зажигай.
Короче, IKor, не томи людей. Тебе ответят максимум через пару часов. Зажигай.
Я так понял счас сами напишем все... Чтоб не томиться... :D
Общий интерфейс с возможностью администрирования на уровне пользователя! О как! :D
А потом подарим на 8 марта если девушка или на 9 марта (праздник окончания женского беспредела) ежели мужчина! :D
Все согласны? :)
... А потом подарим на 8 марта если девушка или на 9 марта (праздник окончания женского беспредела) ежели мужчина! :D
Все согласны? :)
Согласны, дарите 9 марта.
Спасибо за такую бурную реакцию. Не ожидал. Я бы вмешался раньше, но только сейчас удалось оторваться от основной работы.
Моя програмка, конечно, будет (я надеюсь...) предназначена не для стульев на гусенечном ходу, а для удобного набора спецификации арматуры холодильных контуров, но нам такие детали не должны мешать.
Уточняю вопрос:
[COLOR=blue]Предметы:[/COLOR]
[COLOR=blue]Модификации предметов:[/COLOR]
[COLOR=red]Аксессуары:[/COLOR]
[COLOR=red]Варианты аксессуаров:[/COLOR]
[COLOR=blue]Стул[/COLOR]
[COLOR=blue]Маленький[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Пластик[/COLOR]
[COLOR=red]Обивка[/COLOR]
[COLOR=red]Ситец[/COLOR]
[COLOR=red]Хлопок[/COLOR]
(*) про цвет обивки забудем совсем - и так сложно;
[COLOR=red]Полокотники[/COLOR]
[COLOR=red]Нет[/COLOR]
[COLOR=blue]Средний[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Обивка[/COLOR]
[COLOR=red]Ситец[/COLOR]
[COLOR=red]Хлопок[/COLOR]
[COLOR=red]Полокотники[/COLOR]
[COLOR=red]Нет[/COLOR]
[COLOR=blue]Большой[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Обивка[/COLOR]
[COLOR=red]Бархат[/COLOR]
[COLOR=red]Хлопок[/COLOR]
[COLOR=red]Полокотники[/COLOR]
[COLOR=red]Есть[/COLOR]
[COLOR=red]Нет[/COLOR]
[COLOR=blue]Стол[/COLOR]
[COLOR=blue]Журнальный[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Бук[/COLOR]
[COLOR=red]Форма[/COLOR]
[COLOR=red]Круглый[/COLOR]
[COLOR=red]Овальный[/COLOR]
[COLOR=red]Прямоугольный[/COLOR]
[COLOR=blue]Письменный[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Бук[/COLOR]
[COLOR=red]Форма[/COLOR]
[COLOR=red]Прямоугольный[/COLOR]
[COLOR=blue]Обеденный[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Бук[/COLOR]
[COLOR=red]Форма[/COLOR]
[COLOR=red]Круглый[/COLOR]
[COLOR=red]Прямоугольный[/COLOR]
[COLOR=blue]Диван[/COLOR]
....
[COLOR=blue]Шкаф[/COLOR]
[COLOR=blue]Книжный[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Бук[/COLOR]
[COLOR=red]Количество отделений[/COLOR]
[COLOR=red]одно[/COLOR]
[COLOR=red]два[/COLOR]
[COLOR=red]три[/COLOR]
[COLOR=blue]Купе[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Бук[/COLOR]
[COLOR=red]Количество отделений[/COLOR]
[COLOR=red]два[/COLOR]
[COLOR=red]три[/COLOR]
[COLOR=blue]Сервант[/COLOR]
[COLOR=red]Материал[/COLOR]
[COLOR=red]Сосна[/COLOR]
[COLOR=red]Дуб[/COLOR]
[COLOR=red]Бук[/COLOR]
[COLOR=red]Количество отделений[/COLOR]
[COLOR=red]одно[/COLOR]
[COLOR=red]два[/COLOR]
[COLOR=red]три[/COLOR]
ИТОГО, как можно видеть, все [COLOR=blue]модификации одного предмета[/COLOR] имеют одни и те же [COLOR=red]аксессуары[/COLOR], но [COLOR=red]варианты аксессуаров[/COLOR] у каждой [COLOR=blue]модификации[/COLOR] - свои.
Кроме того, разные [COLOR=blue]предметы[/COLOR] могут иметь одни и те же [COLOR=red]аксессуары[/COLOR].
Подобное решение задачи (в Excel) работает только при небольшом количестве [COLOR=blue]предметов[/COLOR] и их [COLOR=red]аксессуаров[/COLOR]. И оно, очевидно, не оптимально. Другое решение в Excel мне кажется слишком сложным и навороченным.
В Access можно создать свои таблицы [COLOR=blue]модификаций[/COLOR] для каждого [COLOR=blue]предмета[/COLOR] и таблицы [COLOR=red]вариантов[/COLOR] для каждого [COLOR=red]аксессуара[/COLOR]. Затем создать сводную таблицу соответсвия [COLOR=red]вариантов аксессуаров[/COLOR] для каждой [COLOR=blue]модификации предметов[/COLOR].
Но далее, передо мной встает проблема: как в новой таблице (или форме) организовать поля со списками для [COLOR=red]вариантов аксессуаров[/COLOR], источники значений которых зависели бы от выбранных [COLOR=blue]модификаций предметов[/COLOR].
Еще раз спасибо за внимание, господа.
[COLOR=green]P.S. Как я задолбался вводить этот светофор...[/COLOR]
Создаешь 4 основных таблицы(как там у тебя):
Предметы
Модификации
Акссесуары
Варианты аксессуаров
В которые заносишь по одному разу ВСЕ позиции которые есть.
Потом создаешь табличку типа
Relations.
C 4-мя полями
ПредметID, МодID и т.д.
Гда прописываешь ВСЕ возможные варианты...
Остается сделать в форме последовательный доступ к полям выбора сначала предмета, потом модификации и т.д.
После выбора предмета, скажем, делаешь запрос к табличке Relations и выбираешь только те модификации которые есть у данного предмета. И даешь их в поле выбора модификаций. Ну и так далее по степени вложенности...
Вроде бы все пока...
стул маленький сосновый ситцевый подлокотники
стул маленький сосновый ситцевый без подлокотников
стул маленький сосновый хлопковый подлокотники
стул маленький сосновый хлопковый без подлокотников
стул маленький пластиковый ситцевый подлокотники
....
я бы выкинул такую программу к ядреной фене. Не стоит думать, что "девочкам за компьютером" это будет совершенно не в лом.
Попробуем поступить хитрее. Вот мое предложение, давайте обсуждать. (причем пока не важно Аксесс это будет или Эксель)
Пусть у любого предмета возможно не более 10 аксессуаров. На самом деле модификация предмета - это тоже аксессуар (в твоем примере - "размер")
У тебя будет таблица ("Главная"), в которой поля называются Аксессуар1, Аксессуар2, ... Аксессуар10.
И будет таблица ("Спецификация"), которая содержит названия акс (надоело писать слово аксессуар, далее - акс) для конкретных предметов, типа такого:
Предмет Акс1 Акс2 Акс3 Акс4 ...
Стул Размер Материал Обивка Подлокотники
Стол Назначение Материал Форма
...
Ну, наверное еще таблица с количеством акс (здесь для стула - 4, для стола - 3).
В Главной у тебя, например, в поле Акс3 для стульев будут значения ситец-хлопок, а для столов - круглый-овальный. Это не должно тебя смущать, ведь юзер этого не увидит. Когда в форме для ввода предметов юзер выберет стул, ты находишь в Спецификации, что для стула Акс1=Размер, Акс2=Материал и т.д. И ПОДПИСИ к полям для ввода соответствующих значений заменяешь на Размер, Материал и т.д. (так даже самому проще - одна форма на все предметы). И в зависимости от количества лишние поля скрываешь. Теперь надо подумать как поэффективнее организовать выбор разрешенных значений.
Я думаю, это просто только в теории. Представляешь, сколько возможных вариантов существует даже в приведенном примере. Если у тебя у какой-нибудь модификации предмета всего 4 аксессуара, по 4 варианта каждого аксессуара - получается сразу 4*4*4*4=256 вариантов. Чтобы программа была удобной, надо всегда ассоциировать пользователя с собой. Как известно, программеры - одни из самых ленивых людей на свете ( :) ), и в данном случае это очень хорошо. Если бы мне, чтобы начать пользоваться программой, пришлось бы вбить туда
стул маленький сосновый ситцевый подлокотники
стул маленький сосновый ситцевый без подлокотников
стул маленький сосновый хлопковый подлокотники
стул маленький сосновый хлопковый без подлокотников
стул маленький пластиковый ситцевый подлокотники
....
я бы выкинул такую программу к ядреной фене. Не стоит думать, что "девочкам за компьютером" это будет совершенно не в лом.
Попробуем поступить хитрее. Вот мое предложение, давайте обсуждать. (причем пока не важно Аксесс это будет или Эксель)
Пусть у любого предмета возможно не более 10 аксессуаров. На самом деле модификация предмета - это тоже аксессуар (в твоем примере - "размер")
У тебя будет таблица ("Главная"), в которой поля называются Аксессуар1, Аксессуар2, ... Аксессуар10.
И будет таблица ("Спецификация"), которая содержит названия акс (надоело писать слово аксессуар, далее - акс) для конкретных предметов, типа такого:
Предмет Акс1 Акс2 Акс3 Акс4 ...
Стул Размер Материал Обивка Подлокотники
Стол Назначение Материал Форма
...
Ну, наверное еще таблица с количеством акс (здесь для стула - 4, для стола - 3).
В Главной у тебя, например, в поле Акс3 для стульев будут значения ситец-хлопок, а для столов - круглый-овальный. Это не должно тебя смущать, ведь юзер этого не увидит. Когда в форме для ввода предметов юзер выберет стул, ты находишь в Спецификации, что для стула Акс1=Размер, Акс2=Материал и т.д. И ПОДПИСИ к полям для ввода соответствующих значений заменяешь на Размер, Материал и т.д. (так даже самому проще - одна форма на все предметы). И в зависимости от количества лишние поля скрываешь. Теперь надо подумать как поэффективнее организовать выбор разрешенных значений.
Что касается предложенной формы хранения данных,то меня честно говоря от этого дрожь пробивает... Не в смысле настолько неправильно (хотя конечно :D ), а в смысле сталкивался я с этим... Как вспомню..:-x Во-первых обязательно найдется предмет с 11-ю акс-ами (закон Мерфи). Во-вторых прога лишается структурности, что есть плохо. Не дай бог конечно ее предстоит админить другому человеку. Это такой страх - что ужасть...
А что касается ввода кучи данных... Мы ж программеры! :D Автоматизировать этот процесс - дело чести! :D И я вижу реальный путь уже сейчас.
Сделать вспомогательную админскую форму, в которой в 4-х СПИСКАХ будут все соответственно предметы, модификации, ... Выделяешь в первых 3-х списках предмет, модификацию, аксеесуар, а в 4-м несколько вариантов аксессуаров. Жмешь волшебную кнопочку "далее" и программка сама добавляет в табличку Relation все выбранное... Очень прогрессивный способ! :D
Во-первых обязательно найдется предмет с 11-ю акс-ами (закон Мерфи).
По-моему, такая беда абсолютно равноценна появлению у стула нового аксессуара - добавляешь поле.
Не совсем понял, давай подробнее.
А что касается ввода кучи данных... Мы ж программеры! :D Автоматизировать этот процесс - дело чести! :D И я вижу реальный путь уже сейчас.
Сделать вспомогательную админскую форму, в которой в 4-х СПИСКАХ будут все соответственно предметы, модификации, ... Выделяешь в первых 3-х списках предмет, модификацию, аксеесуар, а в 4-м несколько вариантов аксессуаров. Жмешь волшебную кнопочку "далее" и программка сама добавляет в табличку Relation все выбранное... Очень прогрессивный способ!
Подожди, а редактировать это все как? Например, добавилась льняная обивка. Хорошо, пишем для этого спецпрогу. Убрали ситцевую - еще прогу. Хлопковая стала хлопчатобумажной - третья... Надо же при этом учитывать разрешенность вариантов. Да и весить твоя базка будет прилично. Что-то мне подсказывает, что предложенный тобой путь ведет нас в серьёзные дебри...
Ну что ж, давай-ка обсудим.
По-моему, такая беда абсолютно равноценна появлению у стула нового аксессуара - добавляешь поле.
Поле Акс11?
И ВСЮДУ нужно будет включить обработку этого поля. Ранее то оно нигде не обрабатывалось...
Не совсем понял, давай подробнее.
Даю!
Не мне тебе рассказывать про нормализацию БД.
По моему твердому убеждению продукт даже для внутреннего использования категорически нельзя писать по принципу "работать будет, а я в случае чего разберусь".
Если есть понятие предмета ,модификации предмета, акссессура МОДИФИКАЦИИ и т.д. то они ДОЛЖНЫ находиться в РАЗНЫХ таблицах и каким-то образом быть связаны между собой. В данном примере мне кажется наиболее очевидным предложенный вариант с таблицей всех связей. Но могут быть и другие (скажем с текстовым полем, состоящим из "0" и "1" указывающим на связи с "родительской" таблицей).
Когда нет четкой структуры данных разобраться в них (особенно другому человеку или самому через годик) почти невозможно. Это ведь не наш путь?!!!!
Подожди, а редактировать это все как? Например, добавилась льняная обивка. Хорошо, пишем для этого спецпрогу. Убрали ситцевую - еще прогу. Хлопковая стала хлопчатобумажной - третья... Надо же при этом учитывать разрешенность вариантов. Да и весить твоя базка будет прилично. Что-то мне подсказывает, что предложенный тобой путь ведет нас в серьёзные дебри...
Админская форма отличается своей независимостью от вводимых данных и ЕДИНСТВЕННОСТЬЮ. Выглядит это так.
Начали делать стулья с обивкой соответственно из льна.
В таблицу ВариантовАксессуаров добавляется новая запись "льняная".
Запускается форма.
Выбирается предмет "Стул" и дальше для всех модификаций и акс-ов для которых добавилась эта пресловутая обивка добавляется вариант "льняная".
Все!
Форма ОДНА!!!
Можно сделать добавочные сервисы в энтой самой форме, по желанию администратора. Скажем если добавилась обивка, то она добавляется всюду... Но это тонкости процесса, зависящие от ТЗ. У нас его нет, поэтому рисуем ОБЩУЮ картину.
Базка будет работать с ЛЮБЫМИ структурами 4-х уровней вложенности. Можно написать и для любого уровня, но энто как раз уже излишнее усложнение конкретной задачи!
Вот!
Давай детально по твоему предложению
Итак, если я правильно понял, ты предлагаешь иметь следующие таблицы:
Таблица "Предметы".
1 поле: "Наименование"
Записи: "Стул",
"Стол"...
Таблица "Модификации".
2 поля: Предмет, Модификация
Записи: Стул, Маленький,
Стул, Средний, ...
Стол, Обеденный,
Таблица "Возможные Стулья".
4 поля: Модификация, Материал, Обивка, Подлокотники
Записи:
маленький сосновый ситцевый подлокотники
маленький сосновый ситцевый без подлокотников
маленький сосновый хлопковый подлокотники
маленький сосновый хлопковый без подлокотников
маленький пластиковый ситцевый подлокотники
...
Таблица "Стулья Пользователя"
Это выборка из "Возможных стульев" плюс, возможно, количество, цену и т.п.
Таблица "Возможные Столы", "Столы пользователя" и т.п.
то есть для каждого предмета по две таблицы - для возможных вариантов, и для ввода.
Я тебя правильно понимаю?
(может, в каких-то деталях ошибся, не суть важно).
Подожди, а редактировать это все как? Например, добавилась льняная обивка.
Кстати, я это вижу как-то вот так:
Кто сказал, что я не предлагаю четкой структуры? По моему, все четко...
Давай детально по твоему предложению
Итак, если я правильно понял, ты предлагаешь иметь следующие таблицы:
Таблица "Предметы".
1 поле: "Наименование"
Записи: "Стул",
"Стол"...
Таблица "Модификации".
2 поля: Предмет, Модификация
Записи: Стул, Маленький,
Стул, Средний, ...
Стол, Обеденный,
Таблица "Возможные Стулья".
4 поля: Модификация, Материал, Обивка, Подлокотники
Записи:
маленький сосновый ситцевый подлокотники
маленький сосновый ситцевый без подлокотников
маленький сосновый хлопковый подлокотники
маленький сосновый хлопковый без подлокотников
маленький пластиковый ситцевый подлокотники
...
Таблица "Стулья Пользователя"
Это выборка из "Возможных стульев" плюс, возможно, количество, цену и т.п.
Таблица "Возможные Столы", "Столы пользователя" и т.п.
то есть для каждого предмета по две таблицы - для возможных вариантов, и для ввода.
Я тебя правильно понимаю?
(может, в каких-то деталях ошибся, не суть важно).
НЕЕЕЕЕЕТ!!!!!
Четыре таблицы (значения как в файле в предыдущем посте ну и ID в каждой таблице разумеется)
+ пятая таблица с пресловутыми 256 записями в которах прописаны возможные связи от предмета к варианту аксессуара.... (содержание - 4 ID из тех таблиц + можно и цену скажем добавить и количество на складе и все что угодно!!!)
НЕЕЕЕЕЕТ!!!!!
Четыре таблицы (значения как в файле в предыдущем посте ну и ID в каждой таблице разумеется)
+ пятая таблица с пресловутыми 256 записями в которах прописаны возможные связи от предмета к варианту аксессуара.... (содержание - 4 ID из тех таблиц + можно и цену скажем добавить и количество на складе и все что угодно!!!)
А как выглядит заказ пользователя в этой системе?
А как выглядит заказ пользователя в этой системе?
Выбор конкретной конфигурации - вот так.
После каждого выбора (от предмета до акс-ра) список следующего выбора ограничивается до необходимого....
Выбор конкретной конфигурации - вот так.
После каждого выбора (от предмета до акс-ра) список следующего выбора ограничивается до необходимого....
Извини, я нечетко сформулировал вопрос. Что будет получаться в итоге (то бишь как выглядит таблица со сформированным заказом)?
P.S. А чегой-то у тебя два индикатора клавиатуры?
Извини, я нечетко сформулировал вопрос. Что будет получаться в итоге (то бишь как выглядит таблица со сформированным заказом)?
P.S. А чегой-то у тебя два индикатора клавиатуры?
1. В итоге мы получим ID пресловутой 5-ой таблицы,
которая состоит из
IDTab5
IDПредмета
IDМодификации
IDАкссессуара
IDВариантаАксессуара
Т.е. мы знаем о выборе клиента ВСЕ!!!
ч.т.д. :D
2. Программа PUNTO Switcher
Прикольная - слов нет!!! Забыл уже где переключается раскладка клавиатуры! :D
punto.ru
Стало быть, одному заказу у тебя соответствует несколько записей в Таблице5? (одна с тканью, одна с подлокотниками и т.д.)
Ну не подумал сразу, что у одного предмета могут быть одновременно несколько разных аксессуаров... Ну бывает... Счас придумаю...
Кстати, вопрос принципиальный....
Зависит ли обивка, скажем, от наличия подлокотников?
Т.е. если стул с подлокотниками, у него та же возможная обивка, что и у стула без подлокотников?
Если нет, то это 5-ый уровень вложенности.
А если да, то....
Тогда храним в таблице Заказ
IDЗаказа
IDПредмета
IDМодификации (их то хоть по одной бывает на предмет???)
А в таблице АксессуарыЗаказа
IDЗаказа
IDАксессуара
IDВариантаАксессуара
Грубо говоря таблица5 нам нужна ТОЛЬКО для того чтобы хранить ограничения и правила, по которым могут распределяться ВариантыАксессуаров по Предметам.
И хранить их именно в таком виде ИМХО правильно.
Кстати интересно почему мне вместо аксессуар, так хочется написать Accessуар?
:D
Конечно, твоим способом можно все сделать, но что-то мне мой больше нравиться. Хотя решать будет IKor (где он, кстати?)
На вкус и цвет товарищей нет!
Просто исходя из второй нормальной формы (кажется) если есть материал "дуб", то он должен храниться только в одном месте... А никак нигде не дублироваться... Ну да ладно...
Во тему забабахали!
Маладтца мы!!!
:D
На вкус и цвет товарищей нет!
Просто исходя из второй нормальной формы (кажется) если есть материал "дуб", то он должен храниться только в одном месте... А никак нигде не дублироваться... Ну да ладно...
Во тему забабахали!
Маладтца мы!!!
:D
Конечно, слово "дуб" должно храниться в одном месте. Я просто, когда свои варианты излагал, для упрощения вместо ИД сами названия ставил. Так то первое, чему учат в базах - это по ИД привязываться.
Огромное спасибо, господа, что приняли мой вопрос так близко к сердцу. Ваши мысли оказались очень важными для понимания мной всей полноты задачи.
Господа, я очень надеюсь, что вы меня не убъете, если я немного изменю постановку задачи. (незначительно).
Моя первая аналогия была достаточно грубым приближением к реальной задаче, но такой серьезный подход заставляет более тщательно сформулировать ТЗ.
Как правильно, заметил Cutty Sark предметы их аксессуары представляют собой одно и тоже (и должны хранится в одной таблице); просто одни предметы просто обязаны находится в комнате (заказе пользователя) только вместе с другими. А другие - нет.
Например, все диваны не имеют никаких сопутствующих им предметов, а любой стол должен иметь стулья и кресла (пожалуйста, уйдем от использования свойств каждого предмета - аксессуаров). Но любой стул или кресло могут находится в (другой) комнате в одиночестве.
Но известно наперед, что рядом с:
- журнальным столиком могут стоять (мягкие кресла или кресла на колесиках) и только (маленькие стулья);
- письменным столом может стоять только (кресло на колесиках) и (маленькие или средние стулья);
- обеденным столом не могут стоять кресла (нет кресел) и могут стоять только (средние или большие стулья).
Мне кажется, что есть два пути решения задачи:
I) создать n таблиц для модификаций всех предметов.
Создать n+1 таблицу для занесения ограничений-связей.
Создать n+2 таблицу или форму, в которой хранить все предметы, которые пользоватеь поставил в комнату (заказ).
Этот способ интуитивно понятен для любого пользователя, но он имеет очевидный недостаток - многотаблиц.
II) создать таблицу предметов (столы, стулья, диваны, кресла ...);
создать таблицу модификаций предметов (где вперемежку записать: маленький, средний, журнальный, большой, обеденный, письменный);
создать таблицу однозначного соответствия модификаций их предметам T3 (по кодам, соответственно)
- T3.1 маленький = стул;
- T3.2 средний = стул;
...
- T3.N письменный = стол;
(или надо наоборот: стол = письменный?)
создать таблицу общих правил T4:
- T4.1 стол + кресло;
- T4.2 стол + стул;
...
причем, наверно, должно быть еще и пустое правило, которое позволит выбирать предметы поодиночке;
и, наконец, создать таблицу частных правил T5(аналог n+1 таблицы из пути I):
вот тут у меня пробел в образовании - не могу сразу представить как это написать - но понимаю, что это возможно;
Создать форму комнаты (заказа пользователя), где можно разместить определенное (наперед заданное) количество предметов, как одиночных, так и предметов, имеющих предметы-спутники.
Поправьте меня, пожалуйста, если я в чем-то ошибаюсь.
P.S. Мне тоже нравится этот переключатель клавиатуры. У него, к стати, есть опция для отключения второго указателя языка. Еще его можно отключить из панели задач.
Рядом с обеденным столом не могут стоять кресла.
Означает ли это, что существует некая последовательность предметов, по которой надо осуществлять выбор. То есть пока не указал, какой стол, нельзя выбирать стулья. Или же нужно реализовать более гибкий механизм: ты можешь выбрать обеденный стол, тогда при выборе стульев не должен быть доступен вариант "кресло", а можешь выбрать кресло, тогда при выборе стола обломишься с "обеденным"?
И еще такой вопрос. Правильно ли я понял, что различные предметы имеют некую "принадлежность" друг другу. То есть конкретное кресло либо принадлежит конкретному столу, либо ничему не принадлежит.
Сам понимаешь, пока все требования не будешь себе чётко представлять, точно всё не опишешь.
P.S. А Punto я себе установил. Осваиваю. Ещё не привык, но прикольно.
Давай-ка уточним.
Рядом с обеденным столом не могут стоять кресла.
Общие правила:
Т4.1 все столы должны иметь кресла;
Т4.2 все столы должны иметь стулья;
...
Частные правила:
...
T4.1.N-2 журнальный стол имеет "мягкое кресло"
T4.1.N-1 журнальный стол имеет "кресло на колесиках"
T4.1.N письменный стол имеет "кресло на колесиках"
T4.1.N+1 обеденный стол имеет ("нет кресел")
Rem Возможно, это правило будет работать даже если его не указывать - я пока не очень понимаю.
...
T4.2.M+1 обеденный стол имеет "средний стул"
T4.2.M+2 обеденный стол имеет "большой стул"
...
То есть пока не указал, какой стол, нельзя выбирать стулья. Или же нужно реализовать более гибкий механизм: ты можешь выбрать обеденный стол, тогда при выборе стульев не должен быть доступен вариант "кресло", а можешь выбрать кресло, тогда при выборе стола обломишься с "обеденным"?
Было бы круто, но необязательно и только в пределах одного предмета, укомплектованного другими предметами - см. ниже.
И еще такой вопрос. Правильно ли я понял, что различные предметы имеют некую "принадлежность" друг другу. То есть конкретное кресло либо принадлежит конкретному столу, либо ничему не принадлежит.
Да - В одной комнате могут стоять 4 предмета (но некоторые из них должны быть доукомплектованы другими предметами):
-письменный стол с креслом на колесиках и средним стулом;
-обеденный стол без кресел, но с большим стулом;
-диван;
-мягкое кресло;
Сам понимаешь, пока все требования не будешь себе чётко представлять, точно всё не опишешь.
Мне не жалко рассказать о реальной задаче, но по-моему, будет понятнее всем, если я найду простые аналогии из обычной жизни.
P.S. Через неделю после того, как я поставил себе Punto на рабочем компьютере, ее увидел наш IT-шник, и еще через день она стояла на 2/3 компьютеров в офисе.
А вот и я.
Мне кажется, что есть два пути решения задачи:
I) создать n таблиц для модификаций всех предметов.
Создать n+1 таблицу для занесения ограничений-связей.
Создать n+2 таблицу или форму, в которой хранить все предметы, которые пользоватеь поставил в комнату (заказ).
Этот способ интуитивно понятен для любого пользователя, но он имеет очевидный недостаток - многотаблиц.
II) создать таблицу предметов (столы, стулья, диваны, кресла ...);
создать таблицу модификаций предметов (где вперемежку записать: маленький, средний, журнальный, большой, обеденный, письменный);
создать таблицу однозначного соответствия модификаций их предметам T3 (по кодам, соответственно)
- T3.1 маленький = стул;
- T3.2 средний = стул;
...
- T3.N письменный = стол;
(или надо наоборот: стол = письменный?)
создать таблицу общих правил T4:
- T4.1 стол + кресло;
- T4.2 стол + стул;
...
причем, наверно, должно быть еще и пустое правило, которое позволит выбирать предметы поодиночке;
и, наконец, создать таблицу частных правил T5(аналог n+1 таблицы из пути I):
вот тут у меня пробел в образовании - не могу сразу представить как это написать - но понимаю, что это возможно;
Создать форму комнаты (заказа пользователя), где можно разместить определенное (наперед заданное) количество предметов, как одиночных, так и предметов, имеющих предметы-спутники.
Поправьте меня, пожалуйста, если я в чем-то ошибаюсь.
Однозначно путь намбер 2.
С небольшим измененьицем...
1. Таблица предметов. Ок.
2. Общая таблица модификаций. Ок.
3. Таблица соответствия модификаций. Ок.
4. Таблица ВСЕХ правил. New.
Смотри что получается:
из таблицы 3 мы имеем все возможные предметы-модификации. У нас есть код маленького стула, журнального столика и т.д.
Соответственно мы в таблице 4 можем записать все правила по такому принципу:
а) код первого выбранного предмета
б) код предмета который МОЖЕТ быть с ним выбран.
Далее возникает вопрос такого порядка.
Может ли иметь скажем обеденный стол 1 большой стул и 2 средних. Или если начали выбирать большие, то все должны быть большими. Это несколько меняет структуру при выборе заказа.
И еще один вопрос.
Если обеденный стол ОБЯЗАН иметь стулья, то можно ли к нему еще выбрать тумбочку какую-нибудь или ТОЛЬКО стулья.
Если ТОЛЬКО стулья, то достаточно оставить в 4-ой таблице записи
ОБЕДЕННЫЙ СТОЛ - СРЕДНИЙ СТУЛ
ОБЕДЕННЫЙ СТОЛ - БОЛЬШОЙ СТУЛ
а если нет, то придется добавить поле
в) Must as boolean (TRUE - обязательн., FALSE - наоборот)
С одиночными предметами просто.
Запись
СРЕДНИЙ СТУЛ - NULL однозначно определяет возможность выбрать только один средний стул.
Таблица заказа будет представлять собой длинную таблицу с
IDЗаказа
IDПредмета (из таблицы3)
А ограничения будут налагаться при вводе заказа в форме. По составу формы и кода можно покумекать, ничего там сложного нет. Можно вводить предметы в список и проверять их по таблице4 на "нормальность". Пока список "не нормальный" - заказ не проводится. Можно делать "предложение" на ввод необходимого сопутствующего предмета. Это как захочется....
Однозначно путь намбер 2.
С небольшим измененьицем...
1. Таблица предметов. Ок.
2. Общая таблица модификаций. Ок.
3. Таблица соответствия модификаций. Ок.
4. Таблица ВСЕХ правил. New.
...
а) код первого выбранного предмета
б) код предмета который МОЖЕТ быть с ним выбран.
Далее возникает вопрос такого порядка.
Может ли иметь скажем обеденный стол 1 большой стул и 2 средних. Или если начали выбирать большие, то все должны быть большими. Это несколько меняет структуру при выборе заказа.
И еще один вопрос.
Если обеденный стол ОБЯЗАН иметь стулья, то можно ли к нему еще выбрать тумбочку какую-нибудь или ТОЛЬКО стулья.
Почему я считаю, что нужна таблица общих правил.
Все столы, независимо от модификации, должны иметь и кресла, и стулья (никаких больше тумбочек). Но у одних модификаций столов - одни модификации стульев, а у других - другие.
Поэтому при выборе в форме (комнате) предмета "стол" должна появиться возможность (мне нравится поле со списком) выбрать к нему еще и стул, и кресло(только одной модификации) , а не только его модификацию.
При выборе одиночных (назовем их простыми) предметов нужно организовать возможность выбора только их модификации.
Тумбочка, стул, кресло или диван могут быть выбраны как отдельные предметы без дополнений.
С одиночными предметами просто.
Запись
СРЕДНИЙ СТУЛ - NULL однозначно определяет возможность выбрать только один средний стул.
Вот это мне не понятно...
А ограничения будут налагаться при вводе заказа в форме. По составу формы и кода можно покумекать, ничего там сложного нет. Можно вводить предметы в список и проверять их по таблице4 на "нормальность". Пока список "не нормальный" - заказ не проводится. Можно делать "предложение" на ввод необходимого сопутствующего предмета. Это как захочется....
Мне хочется дать возможность выбора предметов в форме (комнате) в следующем виде:
- выбор типа предмета;
- определение простой это предмет или составной;
- в первом случае организация поля для выбора модификации предмета;
-во втором - поля для выбора модификации основного предмета и полей для выбора модификаций всех дополнительных предметов (количество известно из таблицы правил);
- выбор нового предмета (количество предметов любой сложности в комнате наперед не известно).
Разделение предметов на простые / составные определяется по отсутствию / наличию их в таблице общих правил. Или даже нет необходимости разделять их на простые и составные: Из таблицы общих правил ясно, что у простых предметов есть 0 (ноль) дополнительных предметов.
Может быть стоит называть составные предметы - наборами?
Но мне пока остается неясным вопрос как сформировать частные правила в соответствии с общими.
К стати, вопрос: можно ли сформировать несколько таблиц модификаций предметов (их просто много), а таблицу соответствия предметов с их модификациями оставить одну (или тоже - нет)?
Условие: предмет может иметь несколько модификаций, а модификация однозначно принадлежит одному предмету.
В этом случае остается ли нужной таблица соответствий, или принадлежность модификации предмета стоит указывать прямо в таблице модификаций?
На сколько я понимаю, это все придется делать в Access'е. А есть ли в нем достаточно мощный математический аппарт для того, чтобы рассчитать значения по умолчанию для вновь выбранного предмета.
Существует несколько исходных данных, которые пользователь выбирает в начале (свойства комнаты: количество людей, тип освещения и др). В соответствии с этим выбором программа должна рекомендовать пользователю первоначальный выбор модификации предмета.
Например, пользователь указал большую комнату на пять человек, работающих за компьютерами (это свойства комнаты).
Затем он выбирает первый предмет в комнате - это стол. И программа предлагает ему по-умолчанию поставить письменный стол (модификаация предмета "стол"), с креслом на колесиках (дополнительный предмет типа "кресло") и ""(пусто) (дополнительный предмет типа "стул").
Програмно производится расчет двух-трех переменных величин (параметры комнаты). Они едины для всей комнаты и нецелесообразно вносить их расчет в условие по-умолчанию для каждого предмета. На их основании программа производит выбор условий по-умолчанию для выбранных предметов.
В Excel эти переменные легко можно хранить в спец. ячейках. А в Access для этого придется подключать аппарат VBA или нет? Как это можно организовать?
Но затем, пользователь меняет кресло на колесиках на "", а "" на "средний стул". Замена осуществляется в соответствии с частными правилами.
Я думаю, если объем всех вышеизложенных данных не превышает 1000 записей, то Access вводить нецелесообразно. Excel - это ОЧЕНЬ мощная штука.
Да одна это штука! Что Excel, что Access...
У Ассеs-a просто лучше настраиваемый интерфейс пользовательский... И куча других примочек именно для хранения и обработки информации. Скажем создание запроса - просто песнь какая-то!
IKor счас раскидаюсь с работой и гляну. Времени нет пока....
Надо, конечно, всё это хорошенько обдумать. Правильная архитектура - половина успеха. Это ещё древние египтяне знали...
По поводу структуры мысли такие:
- Нужно создать библиотеку "стандартных комнат" с заранее определенным набором предметов, но окончательный выбор модификаций предметов в комнате каждый раз свой и зависит от исходных данных и выбора пользователя.
- Создать возможность пополнять библиотеку новыми комнатами;
- Создать проект(ы) здания с несколькими комнатами. Желательно иметь возможность выбирать и модифицировать (только внутри проекта) стандартные комнаты, создавать новые, и пополнять библиотеку стандарнтых;
Возможно, стоит проекты зданий формировать в отдельных файлах.
Я думаю, если объем всех вышеизложенных данных не превышает 1000 записей, то Access вводить нецелесообразно. Excel - это ОЧЕНЬ мощная штука.
Больше. Модификаций всего две-три тысячи. Предметов - сотня-другая. Из них составных - приблизительно 1/3.
Значит, все-таки Access.
IKor счас раскидаюсь с работой и гляну. Времени нет пока....
Спасибо, я тоже сижу как в Турции. Ближе к вечеру, обязательно сюда загляну.