Форум MySQL

Нет, я, конечно, за отдельные сущности в данном вопросе, просто у всех разные мысли на этот счет, поэтому я и спросил. Благодарю за ответ!

Тогда - конечно.
Только будет ли она полезна Вам без опоры на физические сущности?

география к пример.

И как будет называться эта сущность?

Ну допустим у меня рубрики и подрубрики это одна сущность. Почему Область и город не могут быть тоже одной сущность?

>1. Таблица streets - это не просто перечисление названий улиц, это именно улицы, находящиеся в определенном городе. Если я убиру оттуда city_id, то в дальнейшем, допустим при переименовании улицы в каком-нибудь городе, например "Ленина" , во всех остальных городах эта улица тоже примет новое название.

Это как раз то, в чем я и пытался убедить Вашего оппонента.

>2. Одна фирма может находиться в одном городе но на разных адресах, поэтому, я думаю нет смысла добавлять city_id в таблицу f_address и следовательно убирать city_id из таблицы firms.


Верно, подразделения могут быть где угодно, но юридическая привязка так или иначе опирается на одну точку ( вне связи с физическим размещением площадок) А значит поле может быть в обеих таблицах, обозначая разные свойства.


>3. По поводу
>>Таблица f_rubrics - фирма может находиться в разных рубриках
>>firm_id int(10)
>>rubric_id int(5)
>>первичный ключ на оба поля (хотя может я и не прав)
>
>Интересная идея, тогда не нужно заморачиваться о размерности f_rubric_id. Но тогда возникает вопрос, не замедлится ли поиск фирмы по рубрикам?

Можно же добавить отдельный индекс по rubric_id или даже встречный уникальный ключ по
rubric_id, firm_id

>4. Такой вопрос - вообще есть еще одна таблица regions в которой указаны области, и таблица cities связана с regions с помощью region_id. Есть ли смысл объединить таблицы regions, cities и streets в одну, ведь по сути это одна сущность, или это не так?

А разве она одна?

PS.

и ёперный театр. ну не трогайте Вы BB-тег code там где он ни в п. ни в к.а.

Позвольте немного разъяснить.

1. Таблица streets - это не просто перечисление названий улиц, это именно улицы, находящиеся в определенном городе. Если я убиру оттуда city_id, то в дальнейшем, допустим при переименовании улицы в каком-нибудь городе, например "Ленина" , во всех остальных городах эта улица тоже примет новое название.

2. Одна фирма может находиться в одном городе но на разных адресах, поэтому, я думаю нет смысла добавлять city_id в таблицу f_address и следовательно убирать city_id из таблицы firms.

3. По поводу

Таблица f_rubrics - фирма может находиться в разных рубриках                                  firm_id     int(10)                                            rubric_id     int(5)   первичный ключ на оба поля (хотя может я и не прав)

Интересная идея, тогда не нужно заморачиваться о размерности f_rubric_id. Но тогда возникает вопрос, не замедлится ли поиск фирмы по рубрикам?

4. Такой вопрос - вообще есть еще одна таблица regions в которой указаны области, и таблица cities связана с regions с помощью region_id. Есть ли смысл объединить таблицы regions, cities и streets в одну, ведь по сути это одна сущность, или это не так?

Вы так и не ответили на каких полях у Вас индексы.
Вот я тут набросал немного кода посмотрите, в частности как реализована зебра.

>Ну вот)) 12 и 17 получается одна компания
тогда не будет двух строк в таблице. И двух первичных ключей тоже не будет.

Ну вот)) 12 и 17 получается одна компания
Теперь посмотрите на мой вариант

Таблица firms - в ней хранятся сами фирмы
firm_id int(10) auto_increment
name varchar(255)

Таблица f_address - в ней хранятся адреса фирм, т.е в одном городе фирма может находиться на разных адресах
f_address_id int(14) auto_increment
firm_id int(10)
city_id int(6)
street_id int(7)
house varchar(10)

я просто скопипастил таблицы автора и внес некоторые изменения, а описания к таблицам остались, вот и ввел в заблуждение
можно конечно было f_address разделить это на две таблицы адреса и филиалы.... но надо ли это.. вопрос спорный