Сегодня в одной уважаемой мной конторе я имел счастье собеседоваться.
И там был поставлен следующий вопрос :
вот имеются 2 копии одной и той же базы —
одна нормализованная , другая нет .
И далее сразу вопрос : какие селекты будут выполяться быстрее на
ненормализованной копии ?
S>А вообще, имхо, термин "вторичный ключ" употребляется редко, поскольку не очен точен. Вторичный ключ можно перевести как secondary key, auxiliary key, в то время как единственно правильный перевод — foreign key. Но это мое личное мнение.
Ты уверен, что это "единственно правильный перевод"?
Мне вот например, кажется, что secondary key называется так в противовес к primary key (логично, правда?)
То есть это ключ таблицы, который не является первичным.
AZ>Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
На самом деле я с трудом себе представляю программера, который хорошо знает SQL, но не понимает основ РСУБД.
Здравствуйте, Igor Trofimov, Вы писали:
S>>А вообще, имхо, термин "вторичный ключ" употребляется редко, поскольку не очен точен. Вторичный ключ можно перевести как secondary key, auxiliary key, в то время как единственно правильный перевод — foreign key. Но это мое личное мнение.
iT>Ты уверен, что это "единственно правильный перевод"?
iT>Мне вот например, кажется, что secondary key называется так в противовес к primary key (логично, правда?) iT>То есть это ключ таблицы, который не является первичным.
iT>Но это никак не foreign key
Это очень легко проверить. Откройте MSDN и поищите понятие secondary key. Его нет. А вот понятие foreign key constraint есть. То же самое — с хелпами по MS SQL Server. То же самое — с хелпами PowerDesigner. Я использовал англоязычную документацию по PostgreSQL, Oracle, Interbase и понятия secondary key не припомню. А если заглянуть в Free Online Dictionary of Computing (http://foldoc.doc.ic.ac.uk/foldoc/index.html), то становится вообще весело:
secondary key — A candidate key which is not selected as a primary key.
Alternate key — Any candidate key that is not the primary key. Also called a secondary key.
А теперь скажите, пожалуйста, имею ли я право докопаться до человека, утверждающего, что ссылочная целостность обеспечивается при помощи вторичных ключей и потребовать объяснений?
Русское понятие "вторичный ключ" сформировалось еще в советские времена. Я сам его употреблял, будучи студентом. Но это очень неточный и двусмысленный термин. Опытному программисту употреблять его не стоит.
Здравствуйте, Igor Trofimov, Вы писали:
AZ>>Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
iT>На самом деле я с трудом себе представляю программера, который хорошо знает SQL, но не понимает основ РСУБД.
Мое убеждение заключается в том, что на SQL можно научить "программировать" любого вменяемого человека. Программировать в кавычках, потому что запросы SQL к программированию имеют очень слабое отношение — это формализованный язык запросов типа "а выдай-ка мне всех женщин парашутисток за последние 20 лет у которых мужья программируют на SQL". SQL является способом сказать чего я хочу. Когда на FoxPro 2.0 появился кастрированный SQL то я очень успешно его использовал будучи полным нулем в реляционной теории.
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Сегодня в одной уважаемой мной конторе я имел счастье собеседоваться. T>И там был поставлен следующий вопрос : T>вот имеются 2 копии одной и той же базы - T>одна нормализованная , другая нет . T>И далее сразу вопрос : какие селекты будут выполяться быстрее на T>ненормализованной копии ?
На первый взгляд, таких селектов должно быть подавляющее большинство. Нормализация, как известно, снижает скорость выполнения запросов.
Здравствуйте, AntZ, Вы писали:
.. AZ>А нормализация я так понимаю тоже введена SQL сервером? Как это ни странно, большинство программистов БД знающих SQL совершенно не знают что такое реляционные алгебра/исчисление и почему большинство современных баз реляционные. Половина программеров не может ответить что выдаст AZ>SELECT * FROM table1 t1, table1 t2 AZ>из оставшейся половины две трети не могут сказать что это такое.
Мне кажется, это не так. Я ни одного такого не знаю. Ну, м/б, некоторые не знают, как это называется.
Хотя! Знаю одного преподавателя с MSных курсов по SQL Server, который не знал, что декартово произведение м/б добыто таким способом. Но, опять-же, он предлагал легальный CROSS JOIN и это нельзя поставить ему в упрек.
AZ>(наиболее общий и универсальный вид JOIN — декартово произведение. Все остальные внутренние JOIN являются проекциями декартова произведения)
AZ>Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
Тут надо уточнить, что такое "основы теории БД", в данном контексте. Умение нормализовать данные — спец этому можно научить за пару дней. Человек может не знать слова "кортеж" и быть вполне вменяемым программистом БД и чувствовать себя в разработке, как рыба в воде. Лично я не помню определения всех нормальных форм — потому, что я ими (определениями) НЕ ПОЛЬЗУЮСЬ в повседневной работе.
Все это, кончено, не отменяет полезности теории — с академической точки зрения, во-первых и с позиции общей терминологии — для ведения дискуссии (опять-же, скорее академического характера).
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Сегодня в одной уважаемой мной конторе я имел счастье собеседоваться. T>И там был поставлен следующий вопрос : T>вот имеются 2 копии одной и той же базы - T>одна нормализованная , другая нет . T>И далее сразу вопрос : какие селекты будут выполяться быстрее на T>ненормализованной копии ?
Постановка вопроса точно такая была? Может имелось в виду не "какие селекты", а "какие SQL-запросы"?
Денормализация выполняется в случаях, когда требуется увеличить производительность запросов выборки данных (select-запросов). Но при этом вырастают затраты на выполнение вставок, изменений и удалений.
Если же имелось в виду именно "какие селекты", то, в общем случае, лично я затрудняюсь ответить. Ответ можно дать только на конкретном примере денормализации. Допустим, мы нарушаем 3НФ и заводим таблицу с полями
S>Постановка вопроса точно такая была? Может имелось в виду не "какие селекты",
Да , вопрос был общим и звучал именно так :
какие селекты будут выполяться быстрее на ненормализованной копии ?
Т.е. я сам должен был привести конкретный вариант с разнесенной и неразнесенной таблицами и показать , что выборка в неразнесенном случае , о котором вы только что упомянули , будет работать быстрее .
Здравствуйте, ttoorrmmoozz, Вы писали:
T>какие селекты будут выполяться быстрее на ненормализованной копии ? T>Т.е. я сам должен был привести конкретный вариант с разнесенной и неразнесенной таблицами и показать , что выборка в неразнесенном случае , о котором вы только что упомянули , будет работать быстрее .
Я думаю что хотели, чтобы ты пример в пример дерево
S>А теперь скажите, пожалуйста, имею ли я право докопаться до человека, утверждающего, что ссылочная целостность обеспечивается при помощи вторичных ключей и потребовать объяснений?
ИМХО — безусловно. Но если вопрос исключительно в терминологии, да еще если и вам доводилось когда-то пользоваться этим же термином в этом же смысле — то (ИМХО, опять таки) не стоит из этого делать неутешительных выводов.
AZ>Когда на FoxPro 2.0 появился кастрированный SQL то я очень успешно его использовал будучи полным нулем в реляционной теории.
Пользоваться может и самый тупой студент. Вопрос о том, чтобы знать.
Т.е. понимать принципы работы и границы возможностей SQL и уметь их [принципы] применять для достижения нужного результата в рамках этих возможностей.
Приведенный выше пример
SELECT * FROM TABLE12, TABLE2
обычно очень наглядно показывает разницу между "умеющим использовать" и "знающим". Хорошо также идут примитивные запросы с группировкой или внешними соединениями.
Здравствуйте, Igor Trofimov, Вы писали:
S>>А теперь скажите, пожалуйста, имею ли я право докопаться до человека, утверждающего, что ссылочная целостность обеспечивается при помощи вторичных ключей и потребовать объяснений?
iT>ИМХО — безусловно. Но если вопрос исключительно в терминологии, да еще если и вам доводилось когда-то пользоваться этим же термином в этом же смысле — то (ИМХО, опять таки) не стоит из этого делать неутешительных выводов.
Поскольку русскоязычный термин "вторичный ключ" таки имеет хождение и если человек все правильно объяснит, то вопрос исчерпан, нет проблем.
Как еще один пример "разночтений", который немного мешает в жизни, можно привести русский вариант термина Use-case diagram. В книгах переводы "Диаграмма прецедентов" и "Диаграмма вариантов использования" встречаются 50/50. С некоторых пор, дабы не бодаться с коллегами, предпочитаю использовать оригинальный, английский термин.
Здравствуйте, Igor Trofimov, Вы писали:
AZ>>Когда на FoxPro 2.0 появился кастрированный SQL то я очень успешно его использовал будучи полным нулем в реляционной теории.
iT>Пользоваться может и самый тупой студент. Вопрос о том, чтобы знать. iT>Т.е. понимать принципы работы и границы возможностей SQL и уметь их [принципы] применять для достижения нужного результата в рамках этих возможностей.
iT>Приведенный выше пример
SELECT * FROM TABLE12, TABLE2
обычно очень наглядно показывает разницу между "умеющим использовать" и "знающим". Хорошо также идут примитивные запросы с группировкой или внешними соединениями.
Еще один простой, но достаточно пакостный вопрос на интервью — по использованию having
