В общем существует БД строящихся объектов, сохраненная в excel. Хотелось бы все это дело перенести в нормальную БД, в данном случае мускул. Есть достаточно хорошо обдуманные требования к тем данным, которые должны храниться в базе данных, но вот составить таблицы не получается, в принципе не знаю как оптимально разбить имеющуюся информацию по таблицам. Надеюсь, что участники форума помогут разобраться с количеством полей и количеством таблиц, а также внешних ключей. Итак, кому интересно, читаем дальше. Вот таблицы, которые я думаю надо как минимум создать.
Объекты
Просто через запятую перечислю те данные, которые хотелось бы отобразить: адрес, название, компании-участники: генподрядчик, заказчик, архитектурная компания, инвестор, техзаказчик; далее фотки (не знаю как хранить, может быть url-ы до картинок в базе записывать) далее комментарии с сортировкой по дате (ну то есть как бы журнал действий, которые производились с объектом, например 1 марта поехал на объект, говорил с прорабом. 3 марта - созвонился с отделом снабжения, выслал прайс и тд), ну и альтернативно можно поле офсайт. Конечно еще поле - первичный ключ.
Компании
Название, адрес, телефоны, имэйл, офсайт. И здесь еще такой вопрос - на одном и том же объекте компания может быть одновременно и техзаказчиком, и архитектурной компанией, либо генподрядчиком и инвестором. И в принципе многие компании могут выступать в различных ролях из перечисленных (см. генподрядчик, заказчик инвестор и тд). Как увязать это с объектами, пока не знаю, может быть там (в таблице объекты) создать поле, допустим genpodryadchik, в котором указывать номер первичного ключа компании, а при запросе сразу выводить инфу о компании, написав предварительно обычным html-ем Генподрядчик: [здесь результаты запроса в БД].
Менеджеры
ФИО, телефон гор, тел мобильный, мэйл, комментарии (ну то есть допустим я могу указать, что с этим человеком познакомился в таких-то обстоятельствах, либо его контакт дал тот-то). Менеджеров надо как-то привязать к компании и к объекту.
Комментарии
ну здесь наверно должны быть поля дата, текст коммента, и еще как-то надо указать, что это коммент к объекту, менеджеру, либо к компании.
В целом пожелания такие, помогите разбить инфу на таблицы. Еще такая проблема, не могу понять как в phpmyadmin создать поле внешний ключ, т.е. первичный ключ могу выбрать из выпадающего списка, а внешний ключ нет. А потом после создания внешнего ключа его же надо еще связать со своим первичным ключом. Как это сделать в phpmyadmin - ума не приложу. Спасибо всем кто дочитал до конца и еще большая благодарность тем, кто сможет чем-нибудь помочь

поглядел ms project в вики, несколько не то, мне другое нужно. Нарисовал небольшую табличку, попробую объяснить по рисунку[img=]

да фотку вставить не получилось, ну вот ссылка рисунок таблицы .
Так вот, предположим, что есть таблица auto, где отображены существующие машины и есть таблица zavod, где отображены заводы, которые выпускают различные части машин. При этом один и тот же завод может как поставлять часть машины (kuzov, kolesa, motor), так и поставлять все части.
Мне кажется разумным, что в столбцах таблицы разных запчастей можно подставить порядковый номер (или id или первичный ключ из таблицы zavod). При запросе же тянуть из БД например для авто BMW смотреть, какой id-шник соответствует какой запчасти, далее допустим выводить название авто из первой таблицы, а вот комплектующие - из второй, на основе id-шника.
Вопросы: что вы думаете по структуре таблиц? В таблице auto, я так понимаю, что столбцы kuzov, kolesa, motor должны быть внешними ключами для столбца id в таблице zavod? Или нет?
Если моя модель верная, то еще один вопрос, как в MySQL через phpmyadmin прописать эти внешние ключи и как их связать с первичным ключом, чтобы:
- при удалении авто, не было ошибки
- а вот при удалении ЗАВОДА, который производит какую-либо часть (кузов, колеса, мотор) какой-либо машины, выскакивала ошибка или предупреждение, что это поле влияет на другие поля?
Может быть есть более оптимальная структура для приведенного примера? Суть в том, что моя задача примерно схожа по сложности, поэтому не имеет смысла говорить, что эта модель обломится при добавлении новых полей или еще чего-нибудь, короче поменьше паранойи. Откликнитесь, кто в курсе, помогите новичку вступить в нелегкий, но увлекательный мир MySQL.