powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Natural vs Synthetic primary keys
24 сообщений из 24, страница 1 из 1
Natural vs Synthetic primary keys
    #34241213
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господа!
Помогите решить спор.
Мой PM сам создал базу.
При этом там имеется две таблицы - ADDRESSES и COMPANY_ADDRESSES.
Он хочет, чтоб в таблице ADDRESSES поля COUNTRY,STREET, HOUSENUMBER составляли
Primary Key. При этом в таблице COMPANY_ADDRESSES есть 3 таких же поля, которые являются FK на таблицу ADDRESSES. Я предложил сделать ID суррогатным и эти три поля уникальными.
Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate. Тогда он согласился так сделать (с ID и тремя уникальными полями), но при этом оставил такие же 3 поля (COUNTRY,STREET, HOUSENUMBER) и в таблице COMPANY_ADDRESSES. И агументировал тем, что если понадобиться прочитать эти поля для COMPANY_ADDRESSES, то Oracle не будет обьединять эти 2 таблицы по ADDRESSES.ID, а просто прочитает их из COMPANY_ADDRESSES.
Честно говоря, я не видел раньше такого и кажется дублировать поля в 2 таблицах неразумно.
Решил посоветоваться - может я неправ.
И вот вопросы
1) В чем преимущества суррогатного ключа?
2) Ускоряет ли дублирование полей в нескольких таблицах быстродействие базы?
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34241464
PM — это Project Manager?
А с чего это он создает базу?
Хотя при вашем уровне, похоже, это оправдано, раз возникают такие глупые прямо скажем споры.

Читать о нормальных формах БД, пока не наступит просветление.
У вас не тот случай, чтобы поступиться принципами нормализации.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34241610
fynda
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Переименовывались:

Страны: Бирма -> Мьянма, Берег слоновой кости -> Кот Дивуар, ГДР -> ФРГ ...
Города: Горький -> Н.Новгород, Калинин -> Тверь, Киров -> Вятка, Рыбинск -> Андропов -> Рыбинск ...
Улицы: просто дофиг в каждом городе

Оно вам надо - после такого переименования отслеживать двусмысленности в ключах? Юзайте суррогатный PK и не парьтесь!
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34241777
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ХМ....
Странно видеть вопрос по архитекруре базы на форуме по java....

Хотя, если по существу вопроса...
Лучше использовать конечно-же суррогатный ключ в качестве РК.
Кроме того, нормализацию баз данных - ещё никто не отменял.
И что это за проблема для ораклового сервера соединить две таблицы?
В общем - учтать матчасть...
А такого глупого РМ - за парту на курсы по базам данных...

Шутка..
Просто ещё новогоднее настроение.

PS. Я, если чесно, и сам РМ, но до такого ещё пока не додумался :-))
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34242199
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34242229
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но в каких случаях надо поступаться нормализацией базы.
Только что имел с ним тим толкинг по скайпу.
Вообще ничего не понимаю.
Например - таблица Persons и таблица Decisions.
В обеих есть поле Username.
Значит человек логиниться - в это время в HTTP сессии запоминается его USERNAME(а не ID из таблицы Persons) и когда этот юзер отправляет запись в таблицу Decisions, то в поле Decisions.Username записывается эта строка. Я говорю, зачем нам в нескольких таблицах хранить этот Username - достаточно в HTTP сессии сохранить ID залогинившегося юзера. А он грит - так будет быстрее. Есть ли такая практика, чтоб хранить одно и тоже поле в нескольких таблицах для скорости?
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34321246
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну что сказать про такое?
Можно только Вам посочуствовать, хотя если РМ из инстранщины - тогда понятно :-)

Кстати по поводу хранения имени пользователя в разных таблицах.
Можно конечно и так, вот только здесь нужно задуматься о том, что к примеру тогда возрастает объём данных и снижается скорость запросов, т.к. число для сервера БД зачастую "весит" меньше чем символьные строки.
И кстати ключи по числовым данным обычно работают быстрее чем по символьным, т.к. математика при этом работает быстрее.
Кроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня. Но это моё ИМХО и обсуждать его не буду, скажу лишь, что например тот же Oracle в своём Collaboration Suite информацию о том, кто создатель объекта, кто его изменятель хранит как числовое значение ключа (ID), а не символьную строку. И при этом всё нормально работает и летает. Но это так к слову.

Так что думаю Вам ещё не раз предстоит ломать копья со своим РМ-ом по этому поводу.

А вот мне интересно, кто у Вас занимается архитектурой системы и базы, есть для этого отдельный человек в команде или нет?
________________________________________________________
Всегда есть куда развиваться, нужно просто этого хотеть.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34322588
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И ещё одна мысль...
oson... А он грит - так будет быстрее...

Допустим, это будет быстрее при записи, а также при селекте из таблицы решений и только из неё.
Но вот если вдруг необходимо будет посмотреть, а кто-же на самом деле этот пользователь USER12345, то есть, узнать его личные данные, то тут уже всё равно придётся лезть в таблицу где эти данные хранятся. А если это ещё нужно будет делать в виде отчёта и с группировкой по каждому пользователю, то тогда по любому нужно будет делать JOIN по полям. Ну а дальше думаю можно подумать о производительности...

И ещё момент, к примеру человек захотел изменить своё имя пользователя, что тогда? Обновлять все его записи во всех таблицах, где есть имя пользователя на новое имя, для сохранения истории? Тоже смысла особого не видно...

PS. Сразу обращусь к тем, кто захочет меня попинать на почве ключей и производительности - отвечать не буду. Т.к. это моё личное мнение, основанное на опыте. Да конечно я знаю, что в нормальных СУБД для построения ключа по строковому полю используется хэш значение этого самого поля записи, которое вычисляется перед тем, как записать ключ, НО, вот как раз-то на вычисление этого хэш значения и будет тратиться дополнительное время. Так что, вот так....
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34323787
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спасибо
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34382239
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
osonспасибо
Пожалуйста.


А кстати, как там дела на поле брани?

Просто интересно, что возобладало, разум или власть?

С Уважением.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34383711
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насчет, кто архитектуру разрабатывает - так он и разрабатывает, и базу, и архитектуру.
Поэтому и менять не очень хочет, доводы странные на мой взгляд приводит.
А закончилось просто - в базе осталось, как он хотел.
Но теперь в сессии храниться все же обьект Person, который однако достается не по id, а по USERNAME. Хорошо, что в java код он не лез :)
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34391497
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да уж...

Нет предела "совершенству" :-)
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34391584
Ы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ы
Гость
удивительно всё. Я реально смеялся:

1) "Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate". (при чём здесь Hibernate)

2) "Лучше использовать конечно-же суррогатный ключ в качестве РК.
Кроме того, нормализацию баз данных - ещё никто не отменял." (а где же нормализация)

3) "Можно конечно и так, вот только здесь нужно задуматься о том, что к примеру тогда возрастает объём данных и снижается скорость запросов, т.к. число для сервера БД зачастую "весит" меньше чем символьные строки.И кстати ключи по числовым данным обычно работают быстрее чем по символьным, т.к. математика при этом работает быстрее."
(абсолютное незнание того, как сервер обрабатывает и хранит различные типы данных)

4) " Т.к. это моё личное мнение, основанное на опыте. Да конечно я знаю, что в нормальных СУБД для построения ключа по строковому полю используется хэш значение этого самого поля записи, которое вычисляется перед тем, как записать ключ" (наверно, неправильно понял. Какой еще хэш?)

Ребята, вы вообще это писали в добром здравии?
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34391595
Зашедший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex KuznetsovКроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня.
Это всего лишь недостаток опыта работы с "системами промышленного уровня"... Таких фигней с денормализованными базами - моря-акияны. Причем некоторые из них - стоят в таких монструозных компаниях (типо оборот > 50 млрд.долл.) и стоят таких неимоверных денеХХХ, что диву даешься.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34395744
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ыудивительно всё. Я реально смеялся:

1) "Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate". (при чём здесь Hibernate)

при том что мэппинги для связей, когда в таблице натуральный кампаудный ключ, и на него ссылается
другая таблица, довольно сложно делать и потом использовать.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34412578
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зашедший Alex KuznetsovКроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня.
Это всего лишь недостаток опыта работы с "системами промышленного уровня"... Таких фигней с денормализованными базами - моря-акияны. Причем некоторые из них - стоят в таких монструозных компаниях (типо оборот > 50 млрд.долл.) и стоят таких неимоверных денеХХХ, что диву даешься.

Уважаемый господин "Зашедший", не Вам судить о моём опыте, из которого и работа с Oracle EBS, Oracle Collaboration Suite, SAP, RB SUN, RB Payroll, Expandable и разработка многих и мнигих прочих, как на MS SQL, так и на Oracle, Interbase, BTrieve и т.д.

Так что не судите, да не судимы будете.

Да, я согласен, что денормализованных данных в промышленных системах вагон и маленькая тележка, к примеру в том же SAP -е, тем не менее не стоит судить о МОИХ высказываниях, не вникнув в суть вопроса...
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34412728
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex Kuznetsov Зашедший Alex KuznetsovКроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня.
Это всего лишь недостаток опыта работы с "системами промышленного уровня"... Таких фигней с денормализованными базами - моря-акияны. Причем некоторые из них - стоят в таких монструозных компаниях (типо оборот > 50 млрд.долл.) и стоят таких неимоверных денеХХХ, что диву даешься.

Уважаемый господин "Зашедший", не Вам судить о моём опыте, из которого и работа с Oracle EBS, Oracle Collaboration Suite, SAP, RB SUN, RB Payroll, Expandable и разработка многих и мнигих прочих, как на MS SQL, так и на Oracle, Interbase, BTrieve и т.д.

Маэстро, покажите на примере из в ашего личного опыта как
Alex Kuznetsovключи по числовым данным обычно работают быстрее чем по символьным, т.к. математика при этом работает быстрее .
Публика ждет.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34413679
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Timm
Маэстро, покажите на примере из в ашего личного опыта как
Публика ждет.

Повторяю из предыдущего поста:

...
PS. Сразу обращусь к тем, кто захочет меня попинать на почве ключей и производительности - отвечать не буду .
...

Публика может ждать сколько угодно.

Для примера, та же публика может поиграть с миллионами записей с ключами, построенными по символьным полям и по числовым (с использованием целых чисел). с замерами производительности и прочими танцами с бубнами.
Ну, или на худой конец, поискать темы форумов по базам данных на интересующую тему.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34413906
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alex Kuznetsov Timm
Маэстро, покажите на примере из в ашего личного опыта как
Публика ждет.

Повторяю из предыдущего поста:

...
PS. Сразу обращусь к тем, кто захочет меня попинать на почве ключей и производительности - отвечать не буду .
...

Публика может ждать сколько угодно.

Для примера, та же публика может поиграть с миллионами записей с ключами, построенными по символьным полям и по числовым (с использованием целых чисел). с замерами производительности и прочими танцами с бубнами.
Ну, или на худой конец, поискать темы форумов по базам данных на интересующую тему.
Ах, конечно. Чесать езыком все горазды. Как только конкретика - я супер-мега гуру, все идут лесом, ничо никому не должен. Фтопку таких м*даков. Простите за мой французский.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34528709
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прошу прощения за оффтопик...

Timm
Ах, конечно. Чесать езыком все горазды. Как только конкретика - я супер-мега гуру, все идут лесом, ничо никому не должен. Фтопку таких м*даков. Простите за мой французский.

Специально для Вас, неверующий и сомневающийся.
Пример довольно прост.
Производился на Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 2) (уж простите ради бога, "супер-мега гуру" - под рукой не оказалось Oracle-ового сервера).

Характеристики машинки:
Compaq nx7400:
RAM: 1 Gb
HDD: FUJITSU MHV2080BH PL IDE 70 Gb - разбит на два по 20 Gb и 50 Gb. Основной раздел - 20 Gb, на нем-же и тестовая база.
CPU: Genuine Intel(R)CPU T2250 частота 1.73 GHz (Centrino Duo)
OS: MS Windows XP Pro SP2
Думаю хватит об этом.
А теперь собственно тестовый пример (предупреждаю сразу, что на тест уйдёт около 3-х минут):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
SET STATISTICS TIME OFF
GO

USE TEMPDB
GO

SET NOCOUNT ON
GO

CREATE TABLE DBO.I1(
I1 INT NOT NULL
)

CREATE TABLE DBO.C1(
C1 VARCHAR( 10 ) NOT NULL
)

print 'Tables created'
print ''
GO

DECLARE @I INT,
        @C VARCHAR( 10 )

SET @I =  1 
WHILE @I <=  2000000 
BEGIN
	INSERT INTO I1 VALUES(@I)
	INSERT INTO C1 VALUES(SUBSTRING('AB00000000', 1 , 10 -LEN(CONVERT(VARCHAR( 8 ),@I)))+CONVERT(VARCHAR( 8 ),@I))
	SET @I = @I+ 1 
END

print 'Tables filled with data'
print '--------------------------------------------------------'
print ''
SET NOCOUNT OFF
GO

print 'Select data from non indexed I1'
print ''
SET STATISTICS TIME ON 
SELECT I1 FROM I1 WHERE I1 BETWEEN  199  AND  27654  OR I1 BETWEEN  1045564  AND  1050031 
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Select data from non indexed C1'
print ''
SET STATISTICS TIME ON 
SELECT C1 FROM C1 WHERE C1 BETWEEN 'AB00000199' AND 'AB00027654' OR C1 BETWEEN 'AB01045564' AND 'AB01050031'
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Creating UNIQUE CLUSTERED INDEX ON I1'
print ''
SET STATISTICS TIME ON 
CREATE UNIQUE CLUSTERED INDEX  PK_I1 ON I1(I1)
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Creating UNIQUE CLUSTERED INDEX ON C1'
print ''
SET STATISTICS TIME ON 
CREATE UNIQUE CLUSTERED INDEX  PK_C1 ON C1(C1)
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Select data from indexed I1'
print ''
SET STATISTICS TIME ON 
SELECT I1 FROM I1 WHERE I1 BETWEEN  199  AND  27654  OR I1 BETWEEN  1045564  AND  1050031 
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Select data from indexed C1'
print ''
SET STATISTICS TIME ON 
SELECT C1 FROM C1 WHERE C1 BETWEEN 'AB00000199' AND 'AB00027654' OR C1 BETWEEN 'AB01045564' AND 'AB01050031'
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Rebuilding index for I1'
print ''
SET STATISTICS TIME ON 
DBCC DBREINDEX(I1)
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Rebuilding index for C1'
print ''
SET STATISTICS TIME ON 
DBCC DBREINDEX(C1)
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Select data from indexed I1'
print ''
SET STATISTICS TIME ON 
SELECT I1 FROM I1 WHERE I1 BETWEEN  10199  AND  127654  OR I1 BETWEEN  1345093  AND  1500031 
SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Select data from indexed C1'
print ''
SET STATISTICS TIME ON 
SELECT C1 FROM C1 WHERE C1 BETWEEN 'AB00010199' AND 'AB00127654' OR C1 BETWEEN 'AB01345093' AND 'AB01500031'

SET STATISTICS TIME OFF 
print '--------------------------------------------------------'
GO

print 'Droping tables'
print ''

DROP TABLE I1, C1
print '-------------------DONE---------------------------------'
GO

Результаты могут быть разными, НО, в основной массе ключ по целочисленному полю работает быстрее.

Так что прежде чем м*удаком называть человека - нужно подумать.
PS. За ваш французский не прощаю .
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34528817
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кузнецов +1
timm не комильфо
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34528937
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppкузнецов +1
timm не комильфо
Сорри, не понял...
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34529047
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
exppкузнецов +1
timm не комильфо
Всем, по -1, Зашедший не хотел никого обидеть. Просто сказал что существует море Legacy систем с дурацкой реализацией PK.
...
Рейтинг: 0 / 0
Natural vs Synthetic primary keys
    #34529088
Alex Kuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Blazkowicz exppкузнецов +1
timm не комильфо
Всем, по -1, Зашедший не хотел никого обидеть. Просто сказал что существует море Legacy систем с дурацкой реализацией PK.
На "Зашедшего" никто и не в обиде, я ему ответил и думаю на этом вопрос с ним исчерпан.

А вот за что по -1 - не понятно :-)
...
Рейтинг: 0 / 0
24 сообщений из 24, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / Natural vs Synthetic primary keys
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]