Автор вопроса: Neco | Web-сайт:neco.pisem.net | ICQ: 247906854
Помогите, пожалуйста, спроектировать базу данныз, в которой одно из полей содержит информацию о товарах. При этом товары могут быть очень различного типа. К примеру, один товар может быть просто "тапочки", а другой "авиабилет". Ест-но, что у первого атрибуты имеют не столь важное и многообразное значение, как у второго. Авиабилет ведь может быть на грузовой или пассажирский рейс. Пассажирский может быть разных классов. Плюс отправные и конечные точки, транзиты, если имеются, время прибытия и отбытия, номер терминала и может кое-что ещё, что я упустил. Конечно можно просто на месте тапочек взять и записать всю инфу, но тогда увеличивается вероятность опечатки оператора, падает скорость набивания базы и увеливается размер самой базы (одни и те же значения). Кроме того нет возможности выбрать подробности о каком-либо пункте. Типа как, если город у нас забит просто в тектовом формате, то я не могу парсить всю строку, вытаскивать оттуда название, искать в базе городов и давать, если есть, ссылку.
А ведь могут быть не только авиарейсы - билеты в кинотеатры, тарифы сотовых операторов да вообще ВСЁ должно заноситься в эту базу по единому шаблону - если один раз что-то забили, то в будущем это надо только выбирать из комбо, но не перебивать.
Я придумал один вариант (одно поле в товара - ссылка на структуру и ещё одно - значения этой структуры), но всё получилось очень запутанно - объяснять операторам, как этим пользоваться - вилы!
Здесь совсем не все так просто как тебе кажется. Если ты попытаешься реализовать все как задумал - получится совсем не простая база данных (а унивнрсально -глобальная информационная система на все случаи жизни) . Если я конечно правильно понял, что ты хочешь сделать.
Реализуй как это делается в бухгалтерии (например в 1С) - разивка товаров по группам.
На продажу (тапочки) - оборот для расчета прибыли.
Внутренние расходы (авиабилеты) - на расходы компании.
Более подробное описание , добавь в необязательные поля ( если компания торгует тапочками, то рейс, время и номер терминала - информация второстепенная, интересная лишь определенному лицу в короткий промежуток врмени).
Но вот цена, как и куда списываются расходы - информация обязательная, доступ к которой должен быть быстрым и легким.
В общем ранжируй информацию на обязательную и нет - отсюда и танцуй.
Блин, я торможу - ничего не понимаю. Может оттого, что я не видел 1С?
Поясню, меня интересует структура БД касательно товаров. Т.е. если бы все торговали только тапочками да лампочками, то получилась бы очень простая база:
tab_Org : [o_id , org_name]
tab_Price: [p_id , org_ptr, good_ptr, price]
tab_Good : [g_id , good_name]
Т.е. я уже не понимаю, что такое:
На продажу (тапочки) - оборот для расчета прибыли.
Внутренние расходы (авиабилеты) - на расходы компании.
Куда мне при таком подходе вставлять необязательную информацию? Создавать дополнительные колонки в таблице товаров? Но я не могу предусмотреть все колонки сразу.
Во первых определись чем торгует компания, то есть на чем зарабатывает бабки ( обычно ассортимент достаточно схож, поэтому проектировать таблицы не сложно).
Это будет условно первая группа товаров.
(При отчетном периоде тебя за информацию по этой группе в первую очередь выдерут )
Еще есть так называемая прочая реализация. Там могут фигурировать совершенно разные товары. Но обычно их в общем весе немного, и продажи нерегулярны, поэтому достаточно общего описания.
Еше есть статья расходы - (это условно авиабилеты для руководства на Канары). Эта группа товаров обычно не перепродается, и идет как затраты.
(За это тебя будут драть во вторую очередь, когда руководство будет прятать прибыль)
Здесь в общем тоже достаточно общего описания, если конечно ресепшен не блондинка и не любовница шефа) А то забудет набить время отлета...
Универсальную систему, создать очень сложно, да и не нужно.
Проконсультируйся с бухгалтерией, финансами, руководством - что им нужно.
Ранжируй мнформацию.
И после этого уже рисуй схему базы.
Программа предназначена для справочного агенства - т.е. фирмы могут быть какие угодно. Поэтому и внутренние расходы принципиального значения не имеют - важно, что эта компания может предоставить.
Универсальную систему, создать очень сложно, да и не нужно.
Группируй товары со схожими свойствами в отдельные таблицы...
Ничего умнее сейчас сказать не могу.
Но хочется уточнить.
Это будет справочник фирм, где будут описаны.
1. Название.
2. Местоположение.
3. Товары, услуги.
4......
Какую информацию должен получить пользователь?
О фирме вообще, или еще и о наличии у нее в данный момент определенного товара/услуги (если последнее - то очень интересный проект).
Адреса в базе тоже есть, но проблема именно в связке фирма-прайс-товары. Я сократил здесь кол-во таблиц, чтобы конкретизировать проблему.
О фирме вообще, или еще и о наличии у нее в данный момент определенного товара/услуги (если последнее - то очень интересный проект).
И о фирме (эта информация хранится в tab_Org) и её товарах. Т.е. оператор должен иметь возможность за пару кликов добраться до всего, что связано с этой организацией. К примеру, запрос может выглядеть так - "сколько стоит самый дешёвый винчестер на 120 гигов в Москве". Тогда оператор делает запрос "найти фирмы по названиюмоск", потом полученную таблицу отсеивает запросом "оставить фирмыбизнес которых содержит орг" потом через Ctrl+A выделяет все записи таблицы и нажимает "показать сводный прайс выделенных фирм", там отсеивает по содержанию в названиивинч|HDD, упорядочивает столбец цен и видит самую низкую цену.
Проблема в том, что если забивать вручную названия:
винчестер 120
винчестер 160
винчестер 200
то во-первых это увеличивающийся размер базы, а самое главное высокая вероятность ошибки и уход товара в небытие - его никто никогда не найдёт по названию.
Что делать?
P.S. Как это выглядит сейчас (~500KB):
http://neco.user.kz/tmp/test.htm
то во-первых это увеличивающийся размер базы, а самое главное высокая вероятность ошибки и уход товара в небытие - его никто никогда не найдёт по названию.
Чтобы избежать всего этого (а ошибка гарантиирована) используются подстановочные ( справочные) таблицы.
Так это обычно реализуется, так реализовано в 1С. Справочник товаров может быть там очень внушительным и структурированным.
Но судя по схеме для тебя это не секрет.
Другого, универсального и автоматизированного пути я не знаю...