Лучшая структура моей таблицы в Perfomance способом:

У меня две разные схемы базы данных

Первая структура:

table 1 : country_master
Column name: id(primary key) country_name 

table 2: State_master
Column name: id(primary key) State_name Country_id(foreign key of country_master)

table 3: City_Master
Column name: id(primary key) city_name State_id(foreign key of State_master)

Вторая структура:

table 1 : Master_table
Column name: id(primary key) name 

table 2 : Sub_master
Column name: id(primary key) name master_id(Foreign key of master Table) subid(id of Sub_master)

Запись первой структуры

table: Country_master
1 india
2 UK
3 USA


table:State_master
1 gujarat 1
2 MP 1
3 Up 1

table:City_master
1 ahmedabad 1
2 surat 1

Запись структуры 2:

table:master_table
1 Country
2 City
3 State

table:master_table
1 india 1 0
2 UK 1 0
3 USA 1 0
4 Gujarat 3 1
5 MP 3 1
6 Up 3 1
7 ahmedabad 2 4 
8 surat 2 4

теперь мой вопрос - это то, что является лучшей схемой моих таблиц для производительности:

3 ответа

Вторая структура будет создавать больше проблем с точки зрения производительности. Поскольку детская таблица имеет все ссылки, ее трудно поддерживать. Рассмотрим сценарий, где вам нужно отметить "капитал" каждого состояния, имеющего данные о критических данных, и что бы вы сделали, чтобы добавить еще один столбец в существующую таблицу и обновить каждую из них? Нет, не очевидно, вместо этого лучше работать, чтобы отделить все города, штаты и страны в отдельной таблице и использовать в запросе, имеющем соединения, так что соединение выполняется над первичным ключом. И самое главное, эти данные не будут изменяться, часто означает, что они остаются постоянными большую часть времени. Они называются поисками, поэтому вам нужно отделить их в таблице. Первая структура хороша при первом появлении, потому что набор данных слишком мал, поскольку данные увеличиваются, что создаст проблемы, следовательно, лучше использовать первую структуру.


Я думаю, что ваша вторая структура таблицы не является полной. Где родитель может быть некластеризованным индексом, тип может быть некластеризованной переменной index.table - это просто пример, чтобы показать

Declare @t table (id int identity(1,1) primary key,names varchar(100)
,parentid int,[type] int)

--where [type] can be enum 1=country,2=states,3 city

 insert into @t values ('india',null,1) ,('gujrat',1,2) 
,('surat',2,3) ,('Bihar',1,2),('Pakistan',null,1)

;with CTE as
(
select * from @t where id=1
union all
select a.* from @t a inner join cte b on a.parentid=b.id
)
select * from cte

ИМХО, Преимущество в том, что если город не является обязательным. Затем в первой структуре таблицы вы должны использовать левое соединение. Во втором примере, каково бы ни было требование, вы всегда можете использовать Внутреннее соединение. Вторая структура - быстро. Также вторая - более гибкая.

Хотя пусть другие комментарии.


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

Например, если один из них, если ваши запросы ищут все состояния в стране, вам нужно будет создать индекс в главном и поддиректоре подкатегории во второй структуре.

licensed under cc by-sa 3.0 with attribution.