Конструкция бизнеса.

[execution]

Как лучше сделать конструкцию бизнесов, дабы избежать чрезмерное использование запросов и более-менее удобную в использовании?

Например в одной базе хранить обобщённую информацию об бизнесе и его владельце, а в других уже добывать информацию?

 Таблица с общей информациией

business_id | business_owner | business_type | business_type_id  

 1 тип бизнеса (например одежды)

business_shop_id | business_show_item_name_1 | business_show_item_price_1 | business_show_item_character_1  

 2 тип бизнеса (автосалон)

 1 таблица

business_auto_show_id | buisness_auto_show_safe | buisness_auto_show_money_in_safe  

 2 таблица

business_auto_show_car_id | business_auto_show_car_model_1 | business_auto_show_car_price_1  

[DeimoS]

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

[execution]

Ток не могу понять, как правильно привязать эти базы.

Например business имеет такие поля: business_id | business_type

business_id - это не AUTO_INCREMENT, по сути ид бизнеса
business_type - тип бизнеса

business_shop - это уже таблица с бизнесом типа - магазин, и имеет такие поля: business_shop_bid | ....

business_shop_bid - ид бизнеса


Получается должно получиться примерно так?

  Открыть/закрыть

CREATE TABLE business 
( 
    business_id INT PRIMARY KEY, 
    business_type INT,  
); 
  
CREATE TABLE business_shop 
( 
    business_shop_bid INT, 
    CONSTRAINT business_busness_shop_fk  
    FOREIGN KEY (business_shop_bid) REFERENCES business (business_id) ON DELETE CASCADE 
);  

[DeimoS]

Мне кажется, тут лучше будет сделать без общей таблицы всё. Общая таблица больше проблем создаст, чем пользы принесёт.
Просто сделай полностью отдельные таблицы под каждый тип бизнеса. И так же отдельные массивы в моде.

[Fallen A.]

Сделать одну таблицу с количеством бизнесов имеет смысл только тогда, когда есть необходимость работать с общими данными, не прибегая к каким-то специфическим значениям или требованиям. Если интересно, могу помочь в этом вопросе за спасибо, но в личку.

[DeimoS]

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

Я бы не советовал создавать самому себе проблемы. Разделение типов бизнесов на отдельные системы и упростит сами системы, и оптимизирует всю систему бизнесов целиком, как минимум, в плане потребления памяти. Да и масштабировать такую систему будет гораздо проще, нежели объединённую.