Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Java [игнор отключен] [закрыт для гостей] / Natural vs Synthetic primary keys / 24 сообщений из 24, страница 1 из 1
08.01.2007, 15:20:26
    #34241213
oson
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
Господа!
Помогите решить спор.
Мой 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
08.01.2007, 19:53:17
    #34241464
Natural vs Synthetic primary keys
PM — это Project Manager?
А с чего это он создает базу?
Хотя при вашем уровне, похоже, это оправдано, раз возникают такие глупые прямо скажем споры.

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Да, я согласен, что денормализованных данных в промышленных системах вагон и маленькая тележка, к примеру в том же SAP -е, тем не менее не стоит судить о МОИХ высказываниях, не вникнув в суть вопроса...
...
Рейтинг: 0 / 0
23.03.2007, 18:54:31
    #34412728
Timm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
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
24.03.2007, 20:20:04
    #34413679
Alex Kuznetsov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
Timm
Маэстро, покажите на примере из в ашего личного опыта как
Публика ждет.

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

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

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

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

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

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

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

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

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
16.05.2007, 12:27:31
    #34528817
expp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
кузнецов +1
timm не комильфо
...
Рейтинг: 0 / 0
16.05.2007, 12:50:36
    #34528937
Alex Kuznetsov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
exppкузнецов +1
timm не комильфо
Сорри, не понял...
...
Рейтинг: 0 / 0
16.05.2007, 13:18:51
    #34529047
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
exppкузнецов +1
timm не комильфо
Всем, по -1, Зашедший не хотел никого обидеть. Просто сказал что существует море Legacy систем с дурацкой реализацией PK.
...
Рейтинг: 0 / 0
16.05.2007, 13:28:31
    #34529088
Alex Kuznetsov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Natural vs Synthetic primary keys
Blazkowicz exppкузнецов +1
timm не комильфо
Всем, по -1, Зашедший не хотел никого обидеть. Просто сказал что существует море Legacy систем с дурацкой реализацией PK.
На "Зашедшего" никто и не в обиде, я ему ответил и думаю на этом вопрос с ним исчерпан.

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


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