В любой таблице SQL должен быть Primary key
"должен быть" потому что "по стандарту" или потому что "так удобнее" ?
Его ответ
" TIGER (20:57:28 17/09/2011)
должен быть, по стандарту
TIGER (20:57:34 17/09/2011)
да и так удобнее"
" TIGER (20:57:28 17/09/2011)
должен быть, по стандарту
TIGER (20:57:34 17/09/2011)
да и так удобнее"
>должен быть, по стандарту
смотря что считать стандартом, если считать best practices стандартом, то да, если стандарт на реляционные бд, то нет, афаир.
смотря что считать стандартом, если считать best practices стандартом, то да, если стандарт на реляционные бд, то нет, афаир.
>должен быть, по стандартусмотря что считать стандартом, если считать best practices стандартом, то да, если стандарт на реляционные бд, то нет, афаир.его ответ:
" TIGER (21:16:28 17/09/2011)
ответ: 12 правил этого самого, Кодда
TIGER (21:16:55 17/09/2011)
и лучше бы добавить, что самое главно - так удобнее"
по 12-ти правилам первичный ключ должен существовать, но он вообще-то может быть и по нескольким столбцам, а не по одному, а может быть, например, строкой, так что ID - это не стандарт.
эээ...
" Alexander (21:24:30 17/09/2011)
по 12-ти правилам первичный ключ должен существовать, но он вообще-то может быть и по нескольким столбцам, а не по одному, а может быть, например, строкой, так что ID - это не стандарт.
TIGER (21:24:53 17/09/2011)
ахххха
TIGER (21:25:10 17/09/2011)
напиши чтобы он больше не отвечал в теме
Alexander (21:25:21 17/09/2011)
то есть?)
TIGER (21:25:22 17/09/2011)
первичный ключ - один, и ты это знаешь
TIGER (21:25:35 17/09/2011)
то, что может быть и строкой это да"
пс. счас регану чела.
" Alexander (21:24:30 17/09/2011)
по 12-ти правилам первичный ключ должен существовать, но он вообще-то может быть и по нескольким столбцам, а не по одному, а может быть, например, строкой, так что ID - это не стандарт.
TIGER (21:24:53 17/09/2011)
ахххха
TIGER (21:25:10 17/09/2011)
напиши чтобы он больше не отвечал в теме
Alexander (21:25:21 17/09/2011)
то есть?)
TIGER (21:25:22 17/09/2011)
первичный ключ - один, и ты это знаешь
TIGER (21:25:35 17/09/2011)
то, что может быть и строкой это да"
пс. счас регану чела.
не надо путать первичный ключ и суррогатный первичный ключ.
первичный ключ - один, и ты это знаешь"ахххха"
Как это связано с несколькими столбцами?
кажется, человек просто путает\подменяет понятия "соответствие стандарту SQL" и "соответствие реляционной модели"
эти слова беру назад, я не успел подумать! Но тема остается
про удобство: есть таблица телки(IDТелки, Name мужики(IDМужики, Name) и третья - ебля(IDТелки,IDМужики). Все ок, заказчик доволен!
Но вот он рожает мысль о том, что таблица ебля оказывается может родить ребенка и он хочет видеть таблицу дети(Idебля,название)ребенка) и дает ее разработать другому прогеру. Делов не много, но почему новый прогер должен вставлять теперь Idебля в таблицу? или есть другие предложения?
Но вот он рожает мысль о том, что таблица ебля оказывается может родить ребенка и он хочет видеть таблицу дети(Idебля,название)ребенка) и дает ее разработать другому прогеру. Делов не много, но почему новый прогер должен вставлять теперь Idебля в таблицу? или есть другие предложения?
в чем тема-то? можно насоздавать любых таблиц. если не собираешься из них читать, то можно и без первичного ключа, конечно.
без суррогатных ключей живется прекрасно, но, возможно, есть какие-то специальные потребности, когда с ними живется еще лучше.
без суррогатных ключей живется прекрасно, но, возможно, есть какие-то специальные потребности, когда с ними живется еще лучше.
про удобство: есть таблица телки(IDТелки, Name мужики(IDМужики, Name) и третья - ебля(IDТелки,IDМужики). Все ок, заказчик доволен! Но вот он рожает мысль о том, что таблица ебля оказывается может родить ребенка и он хочет видеть таблицу дети(Idебля,название)ребенка) и дает ее разработать другому прогеру. Делов не много, но почему новый прогер должен вставлять теперь Idебля в таблицу? или есть другие предложения?то есть ты утверждаешь что в третьей таблице обязтельно сразу же кроме двух колонок `IDТелки`,`IDМужики` надо еще колонку ID ?
и ты не будешь нанимать на работу тех кто думает иначе? а тех кто не создат такую колонку сразу же - уволишь?)
на самом деле, обязательно. иначе у тебя ебли не будут различаться
Он немного исказил смысл. изначально спор был такой - в третьей таблице хранится строка если ебля была , и не хранится, если не было.
тут различать не требуется
тут различать не требуется
вы приложение для вконтакта дизайните?
В ответ на:Да, именно с такими я работать не буду!
про удобство: есть таблица телки(IDТелки, Name мужики(IDМужики, Name) и третья - ебля(IDТелки,IDМужики). Все ок, заказчик доволен! Но вот он рожает мысль о том, что таблица ебля оказывается может родить ребенка и он хочет видеть таблицу дети(Idебля,название)ребенка) и дает ее разработать другому прогеру. Делов не много, но почему новый прогер должен вставлять теперь Idебля в таблицу? или есть другие предложения?
то есть ты утверждаешь что в третьей таблице обязтельно сразу же кроме двух колонок `IDТелки`,`IDМужики` надо еще колонку ID ?
и ты не будешь нанимать на работу тех кто думает иначе? а тех кто не создат такую колонку сразу же - уволишь?)
такс, еще один пардон. Я имел ввиду, что ебля может быть только одна(для примера) !
вы приложение для вконтакта дизайните?Нет, я ни в каких контактах не работаю. Просто меня стали спрашивать почему я отказываю некоторым людям и решил сросить мнени на форуме
Да, именно с такими я работать не буду!Итого , что имеем. пришел заказчик. попросил таблицу девок и мужиков и хранение факта того что A отымел B
я предлагаю создать третью таблицу из двух колонок (id_man, id_woman). по запросу на факт того что A отымел B, смотреть, есть ли в таблице строка (A,B) (и тут соотвественно для ускорения селекта замутить индексы или ключи).
зачем в этой таблице еще третья колонка ID ?
В ответ на:Тем кто стесняется можете выходить.
Да, именно с такими я работать не буду!
Итого , что имеем. пришел заказчик. попросил таблицу девок и мужиков и хранение факта того что A отымел B
я предлагаю создать третью таблицу из двух колонок (id_man, id_woman). по запросу на факт того что A отымел B, смотреть, есть ли в таблице строка (A,B) (и тут соотвественно для ускорения селекта замутить индексы или ключи).
зачем в этой таблице еще третья колонка ID ?
Про тему - она остается:
про удобство: есть таблица телки(IDТелки, Name мужики(IDМужики, Name) и третья - ебля(IDТелки,IDМужики). Все ок, заказчик доволен!
Но вот он рожает мысль о том, что таблица ебля оказывается может родить ребенка и он хочет видеть таблицу дети(Idебля,название)ребенка) и дает ее разработать другому прогеру. Делов не много, но почему новый прогер должен вставлять теперь Idебля в таблицу? или есть другие предложения?
Только одно уточнение - примари ключ здесть - (IDТелки, Name
Вариантов масса:
1. Добавить имя ребёнка в таблицу ебля
2. В таблице ребёнок иметь ключём IDбаба, IDмужик
Всё зависит от условий задачи.
1. Добавить имя ребёнка в таблицу ебля
2. В таблице ребёнок иметь ключём IDбаба, IDмужик
Всё зависит от условий задачи.
- примари ключ здесть - (IDТелки, Name(IDТелки, IDМужики)
а когда третий пол появится, как будешь переделывать?
а когда третий пол появится, как будешь переделывать?Когда он появится БД будет не нужна
когда писали софт, кодирующий год двумя цифрами, думали так же.
а когда третий пол появится, как будешь переделывать?Спор не об этом.
Видимо немного не понятна суть спора.
С мужиками и телками не удачный пример
Перефразирую.
Есть баннеры, а есть рекламодатели.
Меня интересует, заказывал ли какой либо рекламодатель когда либо какой то конкретный баннер
Я создаю таблицу banner2user (banner_id, user_id)
Если рекламодатель заказывал баннер, я INSERTю строку, если мне надо узнать заказывал ли, \я делаю SELECT
и не понимаю зачем тут третья колонка нужна.
это вопрос тигру.
Вариантов масса:Первый вариант отлетучивается и ты с этим согласен - данных будет много, и таблиц ссылающихся на эту может быть много.
1. Добавить имя ребёнка в таблицу ебля
2. В таблице ребёнок иметь ключём IDбаба, IDмужик
Всё зависит от условий задачи.
Со вторым я согласен, но предположим кто-нибудь спросит - назови мне имя ебли и что делать? Ты будешь называть их имена? А если они на иврите тоже? Может мы отклонились от тему, но я считаю, что первичный ключ должен указывать на int, а не куда-то еще, и он дожен быть!
имя ебли
В ответ на:Ответ простой. Ты сделал все правильно по ТЗ. Оно работатет.
а когда третий пол появится, как будешь переделывать?
Спор не об этом.
Видимо немного не понятна суть спора.
С мужиками и телками не удачный пример
Перефразирую.
Есть баннеры, а есть рекламодатели.
Меня интересует, заказывал ли какой либо рекламодатель когда либо какой то конкретный баннер
Я создаю таблицу banner2user (banner_id, user_id)
Если рекламодатель заказывал баннер, я INSERTю строку, если мне надо узнать заказывал ли, \я делаю SELECT
и не понимаю зачем тут третья колонка нужна.
это вопрос тигру.
Но тема не об этом.
Если тот же работодатель захочет таблицу "Ребенок" от твоей(я не собираюсь придумывать откуда он может появиться. но она может появиться то что, ID вставлять в твою таблицу?Или если есть Primary Key ссылаться на него? - banner_id, user_id и еще тучу колонок которую ты запрогал?
а если он потребует быстро выдавать ему количество баннеров, который заказал конкретный рекламодатель,
ты уволишь того, кто заранее триггер не предусмотрел?
ты уволишь того, кто заранее триггер не предусмотрел?
а если он потребует быстро выдавать ему количество баннеров, который заказал конкретный рекламодатель,1) А по ключу примари это не сделать что ли?
ты уволишь того, кто заранее триггер не предусмотрел?
2) Триггеры это администраторы БД, а не программисты. Это уже другой вопрос
Мы отклонились от темы. Нужен ли Primary Key в ЛЮБОЙ ТАБЛИЦЕ! для заказчика, для своих делайте что хотите
Еще пример. Есть большая-большая табличка со статистикой/логами чего-нить: (дата-время, тип события, количество событий). Зачем тут может быть нужен primary key?
Вот чем он может мешать я могу придумать - без него намного проще такую табличку шардить между серверами, сливать обратно и совершать прочие хаотичные действия с данными. А вот зачем он может быть нужен я придумать не могу.
Вот чем он может мешать я могу придумать - без него намного проще такую табличку шардить между серверами, сливать обратно и совершать прочие хаотичные действия с данными. А вот зачем он может быть нужен я придумать не могу.
1) А по ключу примари это не сделать что ли?2) Триггеры это администраторы БД, а не программисты. Это уже другой вопросМы отклонились от темы. Нужен ли Primary Key в ЛЮБОЙ ТАБЛИЦЕ! для заказчика, для своих делайте что хотитеИтак, что имеем, если слегка отклониться от темы.Вернее что я понял
По твоей логике, если у нас в базе есть таблица, хранящая бинарное отношение вида
"А отжаривал Б" или "А заказывал Б" или " А ездил к Б" и тому подобное, то всенепременно это должна быть таблица минимум из трех колонок (ID, A_ID, B_ID) а всех кто сделал не так ты уволняешь независимо от тех задания?)
Еще пример. Есть большая-большая табличка со статистикой/логами чего-нить: (дата-время, тип события, количество событий). Зачем тут может быть нужен primary key?Хорошо.
Вот чем он может мешать я могу придумать - без него намного проще такую табличку шардить между серверами, сливать обратно и совершать прочие хаотичные действия с данными. А вот зачем он может быть нужен я придумать не могу.
Просто для примера - приходит твой начальник, смотрит на все это и говорит - пришлика эту строку мне для анализа и чтобы я мог ее НАЙТИ в бд, а то вдруг аутлук исказит.
Ну или самый лучший пример - удали-ка мне эту строку
вернитесь, пожалуйста, в IM. только зря лампочку зажигаете.
Ну или самый лучший пример - удали-ка мне эту строкуDELETE FROM tablename WHERE date = "2011-08-09 12:45:34" AND event_id = 10 AND event_cnt = 20 LIMIT 1;
В ответ на:Я вообще считаю этот спор бестолковым - удали мне строку не знаю как назвать кто кого-то отжаривал 19 сентября или примерно время я не помню, но он это делал несколько раз в день.
1) А по ключу примари это не сделать что ли?2) Триггеры это администраторы БД, а не программисты. Это уже другой вопросМы отклонились от темы. Нужен ли Primary Key в ЛЮБОЙ ТАБЛИЦЕ! для заказчика, для своих делайте что хотите
Итак, что имеем, если слегка отклониться от темы.Вернее что я понял
По твоей логике, если у нас в базе есть таблица, хранящая бинарное отношение вида
"А отжаривал Б" или "А заказывал Б" или " А ездил к Б" и тому подобное, то всенепременно это должна быть таблица минимум из трех колонок (ID, A_ID, B_ID) а всех кто сделал не так ты уволняешь независимо от тех задания?)
В ответ на:А если колонок будет 50, такой же скрипт напишешь?
Ну или самый лучший пример - удали-ка мне эту строку
DELETE FROM tablename WHERE date = "2011-08-09 12:45:34" AND event_id = 10 AND event_cnt = 20 LIMIT 1;
Колонки с содержательными данными три. По условию.
вернитесь, пожалуйста, в IM. только зря лампочку зажигаете.В IM мы уже разобрались, решили общество спросить.
Колонки с содержательными данными три. По условию+1
получается что если 50 колонок, то ID нужен, а если три , то не нужен?)
непонятно, что вы здесь ждете.
модельная задача, описанная в треде, какая-то притянутая за уши и не помогает раскрыть вопрос.
абстрактные соображения изложены, например, здесь: http://en.wikipedia.org/wiki/Surrogate_key
модельная задача, описанная в треде, какая-то притянутая за уши и не помогает раскрыть вопрос.
абстрактные соображения изложены, например, здесь: http://en.wikipedia.org/wiki/Surrogate_key
В ответ на:Вопрос общий, нужно ли проектировщику БД давать колонке ID примари ключ или примари индекс, в не зависимости от того сколько колонок будет вообще!
Колонки с содержательными данными три. По условию
+1
получается что если 50 колонок, то ID нужен, а если три , то не нужен?)
В ответ на:Зачем это делать - да может быть 3 колонки, может быть таблица вырастет до 50, которые будут входить в примари кей или ключ - заведомо он не может этого знать
В ответ на:
Колонки с содержательными данными три. По условию
+1
получается что если 50 колонок, то ID нужен, а если три , то не нужен?)
Вопрос общий, нужно ли проектировщику БД давать колонке ID примари ключ или примари индекс, в не зависимости от того сколько колонок будет вообще!
общий ответ --- это бывает полезно, но по стандарту SQL не является обязательным
общий ответ --- это бывает полезно, но по стандарту SQL не является обязательнымСпасибо. Я знаю что стандарта SQL такого нет, интересно просто кто считает это нужным делать, а кто нет.
Я знаю что стандарта SQL такого нет, интересно просто кто считает это нужным делать, а кто нет.хмм...стартовый пост Лексуса кажется был практически противоположным по смыслу
Спасибо. Я знаю что стандарта SQL такого нет, интересно просто кто считает это нужным делать, а кто нет.Я считаю ненужным. у меня в рабочей базе 14 таблиц которые хранят бинарные отношения.
таблица баннеров и рекламодателей - реальная
и ни в одной такой таблице у меня нету отдельной третьей колонки ID
все индексы созданы на двух колонках
В ответ на:ну мы тут развили немного тему. Стандарт есть, правило Кодда номер 2. Я имел ввиду, что примари кей должен быть каким-нибудь числом.
Я знаю что стандарта SQL такого нет, интересно просто кто считает это нужным делать, а кто нет.
хмм...стартовый пост Лексуса кажется был практически противоположным по смыслу
В ответ на:Это и есть вопрос! я не говорю же что это неправильно, я говорю о том, что может бы так, что потом эти таблицы могут расширяться! И сколько потом будет таких ключевых колонок? И почему новый прогер должен все эти изменения на всякий случай проверять в связях с другими таблицами?
Спасибо. Я знаю что стандарта SQL такого нет, интересно просто кто считает это нужным делать, а кто нет.
Я считаю ненужным. у меня в рабочей базе 14 таблиц которые хранят бинарные отношения.
таблица баннеров и рекламодателей - реальная
и ни в одной такой таблице у меня нету отдельной третьей колонки ID
все индексы созданы на двух колонках
Вот тебе другой модельный пример.
Таблицы:
Люди (ID, ИНН, Имя, Дата начала действия) — хранит человеков с историей, нам нужно отслеживать изменение имени во времени.
Счета (ID, Номер счёта, ID человека, Название, Дата начала действия) — то же но со счетами один счёт принадлежит одному человеку.
Проводки (ID, Дата проводки, ID счета).
И вот тебе говорят что оказывается месяц назад Иванов сменил фамилию на Петров. И ты получаешь веерное обновление: ты заводишь новую запись для Иванова, создаёшь новые записи для его счетов, и ищешь все проводки по старым счетам и тебе приходится их обновляеть.
Если в базе не 3 таблицы, а 300, то это очень большая проблема.
Таблицы:
Люди (ID, ИНН, Имя, Дата начала действия) — хранит человеков с историей, нам нужно отслеживать изменение имени во времени.
Счета (ID, Номер счёта, ID человека, Название, Дата начала действия) — то же но со счетами один счёт принадлежит одному человеку.
Проводки (ID, Дата проводки, ID счета).
И вот тебе говорят что оказывается месяц назад Иванов сменил фамилию на Петров. И ты получаешь веерное обновление: ты заводишь новую запись для Иванова, создаёшь новые записи для его счетов, и ищешь все проводки по старым счетам и тебе приходится их обновляеть.
Если в базе не 3 таблицы, а 300, то это очень большая проблема.
И сколько потом будет таких ключевых колонок?Если у тебя меняются альтернативные ключи, то это уже изменение логики и наличие суррогатных первичных ключей не спасёт, всё равно нужно проверять/изменять весь код под новые требования.
Вот тебе другой модельный пример.Я могу ошибаться, но я бы сделал 3-ю таблицу - смена фамилии. И брал бы новую фамилию оттуда. Человек-то тот же самый?
Таблицы:
Люди (ID, ИНН, Имя, Дата начала действия) — хранит человеков с историей, нам нужно отслеживать изменение имени во времени.
Счета (ID, Номер счёта, ID человека, Название, Дата начала действия) — то же но со счетами один счёт принадлежит одному человеку.
Проводки (ID, Дата проводки, ID счета).
И вот тебе говорят что оказывается месяц назад Иванов сменил фамилию на Петров. И ты получаешь веерное обновление: ты заводишь новую запись для Иванова, создаёшь новые записи для его счетов, и ищешь все проводки по старым счетам и тебе приходится их обновляеть.
Если в базе не 3 таблицы, а 300, то это очень большая проблема.
Я могу ошибаться, но я бы сделал 3-ю таблицу - смена фамилии. И брал бы новую фамилию оттуда. Человек-то тот же самый?Ну то что я нарисовал это и есть таблица смена фамилии. ИНН + Дата — натуральный ключ.
У счёта Номер + Дата — натуральный ключ, а название так же может меняться.
В ответ на:Не совсем согласен. Был ключ ФИО, Потом оказались однофамильцы, ввели номер телефона. Зачем мне менять логику БД, если счет должен оплатить одни из них, как указано в паспорте? А потом оказется что все они по одному телефону и мы дальше вводим номир комнаты, номер кровати, вернахяя или нижнаяя и т.д.
И сколько потом будет таких ключевых колонок?
Если у тебя меняются альтернативные ключи, то это уже изменение логики и наличие суррогатных первичных ключей не спасёт, всё равно нужно проверять/изменять весь код под новые требования.
Не совсем согласен. Был ключ ФИО, Потом оказались однофамильцы, ввели номер телефона. Зачем мне менять логику БД, если счет должен оплатить одни из них, как указано в паспорте?Изначально кривой дизайн никто не отменят. Тем не менее скажем ты принимаешь платежи через банк и определяешь кто же заплатил по ФИО (ты же считал что это PK теперь когда пошли однофамильцы один фиг придётся переделывать взаимодействие с Банком, это и есть изменение логики.
В ответ на:1) я может тебя не так понял - в теме было, что примари ключ или индеск не нужно? это так?
В ответ на:
И сколько потом будет таких ключевых колонок?
Если у тебя меняются альтернативные ключи, то это уже изменение логики и наличие суррогатных первичных ключей не спасёт, всё равно нужно проверять/изменять весь код под новые требования.
Не совсем согласен. Был ключ ФИО, Потом оказались однофамильцы, ввели номер телефона. Зачем мне менять логику БД, если счет должен оплатить одни из них, как указано в паспорте? А потом оказется что все они по одному телефону и мы дальше вводим номир комнаты, номер кровати, вернахяя или нижнаяя и т.д.
2) это не по-стандарту, я считаю, что так ключ или индекс должен быть числом - int32, int64 не важно. Мне кажется гораздно удобнее говорить о человеке (это для примера) - номер 1576, чем ФИО, индекс такой, ИНН такой и еще что там могут придумать дальше.
В ответ на:Если мы про БД банка то да, нужно переделывать.
Не совсем согласен. Был ключ ФИО, Потом оказались однофамильцы, ввели номер телефона. Зачем мне менять логику БД, если счет должен оплатить одни из них, как указано в паспорте?
Изначально кривой дизайн никто не отменят. Тем не менее скажем ты принимаешь платежи через банк и определяешь кто же заплатил по ФИО (ты же считал что это PK теперь когда пошли однофамильцы один фиг придётся переделывать взаимодействие с Банком, это и есть изменение логики.
>2) это не по-стандарту
про какой стандарт ты сейчас говоришь?
>я считаю, что так ключ или индекс должен быть числом - int32, int64 не важно.
это ты считаешь, или кто-то, стоящий у истоков реляционной алгебры/стандарта ansi sql ?
>Мне кажется гораздно удобнее говорить о человеке (это для примера) - номер 1576, чем ФИО, индекс такой, ИНН такой и еще что там могут придумать дальше.
а вот мне кажется, что гораздо удобнее говорить о человеках, как о никах на форуме.
ещё раз, пожалуйста, сформулируй изначальный постулат, с которого тема начиналась, а то весь ваш разговор в аське нам тут не привели.
про какой стандарт ты сейчас говоришь?
>я считаю, что так ключ или индекс должен быть числом - int32, int64 не важно.
это ты считаешь, или кто-то, стоящий у истоков реляционной алгебры/стандарта ansi sql ?
>Мне кажется гораздно удобнее говорить о человеке (это для примера) - номер 1576, чем ФИО, индекс такой, ИНН такой и еще что там могут придумать дальше.
а вот мне кажется, что гораздо удобнее говорить о человеках, как о никах на форуме.
ещё раз, пожалуйста, сформулируй изначальный постулат, с которого тема начиналась, а то весь ваш разговор в аське нам тут не привели.
>2) это не по-стандартуХочешь о людях, давай о них, мне все равно.
про какой стандарт ты сейчас говоришь?
>я считаю, что так ключ или индекс должен быть числом - int32, int64 не важно.
это ты считаешь, или кто-то, стоящий у истоков реляционной алгебры/стандарта ansi sql ?
>Мне кажется гораздно удобнее говорить о человеке (это для примера) - номер 1576, чем ФИО, индекс такой, ИНН такой и еще что там могут придумать дальше.
а вот мне кажется, что гораздо удобнее говорить о человеках, как о никах на форуме.
ещё раз, пожалуйста, сформулируй изначальный постулат, с которого тема начиналась, а то весь ваш разговор в аське нам тут не привели.
Если хочешь смысл темы, то нужно дождаться утра, потому что ее владелец сейчас в самолете.
"он себя неуютно чувствует, если в таблице у него нету праймари кея" это я, и это первый вопрос из мною заданных тебе. Вот главный вопрос в теме, остальные разраслись.
По поводу int-а, я видел многих людей и видел много мнений, но я их не приведу. Сейчас я один так утверждаю!
в тайланде 6 полов. официально.
PS или 7
PS или 7
в тайланде 6 полов. официально.Шесть? я думал только три.. надо рюхнуть
в австралии вон уже сделали
пофиг. смотри на что я отвечал.
>"он себя неуютно чувствует, если в таблице у него нету праймари кея" это я, и это первый вопрос из мною заданных тебе. Вот главный вопрос в теме, остальные разраслись.
я не понял, так что за вопрос-то?
я не понял, так что за вопрос-то?
В ответ на:Мы здесь спорили в основном что primary key это int, что к тебе не отностися, если не сложно можешь свою точку зрения сказать?
>2) это не по-стандарту
про какой стандарт ты сейчас говоришь?
>я считаю, что так ключ или индекс должен быть числом - int32, int64 не важно.
это ты считаешь, или кто-то, стоящий у истоков реляционной алгебры/стандарта ansi sql ?
>Мне кажется гораздно удобнее говорить о человеке (это для примера) - номер 1576, чем ФИО, индекс такой, ИНН такой и еще что там могут придумать дальше.
а вот мне кажется, что гораздо удобнее говорить о человеках, как о никах на форуме.
ещё раз, пожалуйста, сформулируй изначальный постулат, с которого тема начиналась, а то весь ваш разговор в аське нам тут не привели.
Хочешь о людях, давай о них, мне все равно.
Если хочешь смысл темы, то нужно дождаться утра, потому что ее владелец сейчас в самолете.
"он себя неуютно чувствует, если в таблице у него нету праймари кея" это я, и это первый вопрос из мною заданных тебе. Вот главный вопрос в теме, остальные разраслись.
По поводу int-а, я видел многих людей и видел много мнений, но я их не приведу. Сейчас я один так утверждаю!
Ну в теме все же написано. Нужно ли (если ТЗ этого НЕ НАДО) создавать в каждой таблице primary key или primary index(вроде так) создавать.
>Мы здесь спорили в основном что primary key это int, что к тебе не отностися, если не сложно можешь свою точку зрения сказать?
моя точка зрения - да хоть int, хоть uuid, главное чтоб было однозначно, работало быстро и головной боли не доставляло.
моя точка зрения - да хоть int, хоть uuid, главное чтоб было однозначно, работало быстро и головной боли не доставляло.
>Мы здесь спорили в основном что primary key это int, что к тебе не отностися, если не сложно можешь свою точку зрения сказать?Ну и отлично. Вопрос на вскидку: ты делаешь таким ключем несколько полей?
моя точка зрения - да хоть int, хоть uuid, главное чтоб было однозначно, работало быстро и головной боли не доставляло.
>Ну и отлично. Вопрос на вскидку: ты делаешь таким ключем несколько полей?
нет, потому что это будет противоречить вышесказанному.
нет, потому что это будет противоречить вышесказанному.
ты делаешь таким ключем несколько полей?Это зависит от задачи и наполнения таблицы. Где-то составной PRIMARY KEY уместен, где-то - нет.
Чёт не въехал в суть спора после прочтения темы.
Всё же вроде просто, в хранилище - должен быть PK (хоть суррогатный, хоть нет чтоб не было неоднозначностей при репортинге, а тех, кто в транзакционной базе сажает PK на высоконагруженную таблицу - надо сажать на кол, т.к. никого не должно волновать, чот из-за PK violation что-то там в таблицу транзакций не вставилось.
Всё же вроде просто, в хранилище - должен быть PK (хоть суррогатный, хоть нет чтоб не было неоднозначностей при репортинге, а тех, кто в транзакционной базе сажает PK на высоконагруженную таблицу - надо сажать на кол, т.к. никого не должно волновать, чот из-за PK violation что-то там в таблицу транзакций не вставилось.
правда стоит учесть, что я даже рядом не стоял со специалистами по БД 
Ну и задачка у вас.
- Таблица с людьми должна быть одна. Имя, пол, адрес, ДР, и т.д. - эти признаки людей.
Id, sName, nSex, AdmDate, AdmUser
- Таблица связей
Id, Id_m, Id_w, dAction, АdmDate, AdmUser
В целях масштабирования задачи на Австралию, или где там много полов, можно для поля Пол завести справочник.
- Таблица с людьми должна быть одна. Имя, пол, адрес, ДР, и т.д. - эти признаки людей.
Id, sName, nSex, AdmDate, AdmUser
- Таблица связей
Id, Id_m, Id_w, dAction, АdmDate, AdmUser
В целях масштабирования задачи на Австралию, или где там много полов, можно для поля Пол завести справочник.
про удобство: есть таблица телки(IDТелки, Name мужики(IDМужики, Name) и третья - ебля(IDТелки,IDМужики). Все ок, заказчик доволен!Заказчик в большинстве случаев не знает, что он хочет на самом деле. Вернее, формулирует свои мысли так, что понять его сложно. "Все ок, заказчик доволен!" - это формальный подход, он не приведет к успеху.
Ну и задачка у вас.ну.. так сказал бы что сам думаешь?!
- Таблица с людьми должна быть одна. Имя, пол, адрес, ДР, и т.д. - эти признаки людей.
Id, sName, nSex, AdmDate, AdmUser
- Таблица связей
Id, Id_m, Id_w, dAction, АdmDate, AdmUser
В целях масштабирования задачи на Австралию, или где там много полов, можно для поля Пол завести справочник.
В ответ на:
про удобство: есть таблица телки(IDТелки, Name мужики(IDМужики, Name) и третья - ебля(IDТелки,IDМужики). Все ок, заказчик доволен!
Заказчик в большинстве случаев не знает, что он хочет на самом деле. Вернее, формулирует свои мысли так, что понять его сложно. "Все ок, заказчик доволен!" - это формальный подход, он не приведет к успеху.
>ну.. так сказал бы что сам думаешь?!
а он тебе, по-твоему, чужие мысли пишет?
а он тебе, по-твоему, чужие мысли пишет?
В моих таблицах всегда есть PK (ID).
Кстати содержание темы неправильное, вопрос был в том:
Что знакомые(я) неуютно чувствую себя, если в таблице у меня нет праймари кея (как правило с именем ID типа int). Я считаю без этого - это не проектировчик БД.
Мнения многих я уже увидел, я просто думал, что еще кто-то ответит.
Что знакомые(я) неуютно чувствую себя, если в таблице у меня нет праймари кея (как правило с именем ID типа int). Я считаю без этого - это не проектировчик БД.
Мнения многих я уже увидел, я просто думал, что еще кто-то ответит.
На мой взгляд, это очевидно.
Такое поле должно быть. Его наличие сильно облегчает дальнейшую работу с таблицей, и написание к ней интерфейса.
Такое поле должно быть. Его наличие сильно облегчает дальнейшую работу с таблицей, и написание к ней интерфейса.
На мой взгляд, это очевидно.Вот у меня куча таблиц без суррогатного ключа (почти все таблицы агрегатов) и куча таблиц где суррогатный ключ есть, но по нему отключена проверка (что бы не мешал секционированию).
Такое поле должно быть. Его наличие сильно облегчает дальнейшую работу с таблицей, и написание к ней интерфейса.
На мой взгляд, это очевидно.Ну тут давали уже ссылку на википедию. Там уже все за и против давно описаны. Мусолить этот вопрос как бы нет смысла.
Такое поле должно быть.
если в таблице у меня нет праймари кея (как правило с именем ID типа int). Я считаю без этого - это не проектировчик БДИ корованы грабить он не умеет!
если в таблице у меня нет праймари кея (как правило с именем ID типа int). Я считаю без этого - это не проектировчик БДНу а че мусолить? Тема и была для этого созданна!
И корованы грабить он не умеет!
Ну а че мусолить? Тема и была для этого созданна!Ну тогда скажу так — люди, писавшие ту статью в википедии считают, что ты в корне неправ. Я в принципе тоже. Иначе тебе стоит дополнить статью и мотивированно опровергнуть все недостатки.
Оставить комментарий
356ft85
такую фразу вот выдал один мой знакомый. я неплотно работаю с БД, но малость удивился такому суждению. оно мне кажется каким то неверным, а он себя неуютно чувствует, если в таблице у него нету праймари кея (как правило с именем ID)кто что может сказать на этот счет?