SQL алиасы
Я по работе часто пишу ёбаных крокодилов на sql. Постепенно пришел к тому что мне удобнее все называть t1 t2 ... tN в рамках текущего подзапроса. Сам текущий подзапрос может быть любым tK для внешнего (к этому) подзапросу.
Почему то мне визуально так парсить проще.
Почему то мне визуально так парсить проще.
Говорят в запросах надо всегда использовать псевдонимы.Правда stackoverflow говорит ровно обратное
http://stackoverflow.com/a/3718800/2724979
P.S. меня кажется наёбывают
Основная идея что не надо писать:
select id, Name from Dempartment join Employee on dept_id = idА будешь ты писать алиасы или имена таблиц не так важно.
я заметил, что id-шники (и если есть другие поля, образующие связь PK->FK) лучше называть не id, а dept_id даже в таблице, где он PK. Тогда такой запрос просто не скомпилируется:
select dept_id, Name from Dempartment join Employee on dept_id = dept_id
Кстати, на это же намекает оригинальная работа Кодда. Там сначала домены и их названия. Dep.Id и Dep_id это один и тот же домен, поэтому незачем давать одному и тому же два разных имени (без обоснованной необходимости).
Говорят в запросах надо всегда использовать псевдонимы. Вопрос. Зачем нужны имена, если всегда используются псевдонимы?Чтобы повысить читабельность, разумеется. По твоей ссылке на stackoverflow как раз и написано, что стоит всегда использовать ссылку на таблицу при обращении к полю. Алиас это будет или полное название не так важно, но представь, что твое название PurchaseOrderHeader упоминается при обращении к каждому полю. Почему писать ссылку на таблицу каждый раз, если в запросе участвует больше одной таблицы я тебе уже писал, повторяться не буду. Захочешь перечитать - найдешь.
Какие правила формирования псевдонима? Например, в C# имя локальной переменной часто (но не всегда) формируется так, для типа PurchaseOrderHeader
purchaseOrderHeader или
orderHeader или
header.
Короткие псевдонимы или неинформативные действительно снижают читабельность, но скажем poh для PurchaseOrderHeader - вполне себе информативно, и не мешает читать.
Что касается использования псевдонимов вместо названий таблиц - называй, кто тебе мешает. Будет у тебя джойн select * from poh cross join nah - очень информативно! Ну а если таблица используется в запросе несколько раз, придется придумывать новые алиасы
Алиас это будет или полное название не так важно, но представь, что твое название PurchaseOrderHeader упоминается при обращении к каждому полю.Представил, и что? Громоздко, зато читаемые слова, а не poh.
А чтобы убрать громоздкость, лишние префиксы можно не писать. Делайте изначально хорошие имена для доменов.
То что запрос будет падать при добавлении таблицы, это несерьезно. Если у вас нет юнит тестов (или linq то у вас весь кафтан в дырках, а вы латаете маленькую дырочку. А если тесты есть, то они покажут, где надо внести изменения, чтобы запрос не падал.
Думаю, что это идет от команд, в которых БД специалисты отделены от программистов, которые пишут приложение. Каждый пытается латать дырочки в своем круге ответственности. В итоге появляется такое уродство как poh.
Как там у Контры в подписи было? Что-то там про узость мышления
Видимо, придется все же повториться. В общем, ты очень слабо представляешь себе задачи БД. Это не только что-то, что отдает данные ормке (тогда вообще пофиг, используешь ты алиасы или нет) или твоей странице.
Это, в том числе, еще и интеграция с другими системами. И если сторонний разработчик вдруг добавит поле с таким же названием, у тебя все упадет. Да, на тестах ты это отловишь и поправишь. А если сразу писать нормально, то даже падать не будет. Разницу понимаешь?
Еще весело, наверное, в субд типа оракла, когда у тебя переменные не выделяются из общей массы идентификаторов, и при добавлении новой колонки в базу, названия могут случайно совпасть. При этом юнит-тест может и не сломается, просто код перестанет работать правильно. Опять срубили проблем на ровном месте
Второй момент - знакомство нового человека с базой. Очень, знаешь, весело разбираться во взаимосвязи данных, когда приходится мышкой наводить на каждое поле, чтобы подсветилось, в какой таблице данные лежат. Это хорошо еще, если IDE показывает, что далеко не всегда бывает (голая SSMS, скажем, подсвечивает только тип). А если это временная таблица, которая еще и создается в другой процедуре - вообще супер
Можно еще аргументы придумать, но этих уже достаточно
По поводу читаемости vs уродские сокращения. Согласен, не очень красиво выглядит, зато читать намного проще. Особенно, если у тебя названия таблиц разной длины. 2-5 буквенные алиасы намного удобнее полных названий таблиц, уж поверь
Видимо, придется все же повториться. В общем, ты очень слабо представляешь себе задачи БД. Это не только что-то, что отдает данные ормке (тогда вообще пофиг, используешь ты алиасы или нет) или твоей странице.
Это, в том числе, еще и интеграция с другими системами. И если сторонний разработчик вдруг добавит поле с таким же названием, у тебя все упадет. Да, на тестах ты это отловишь и поправишь. А если сразу писать нормально, то даже падать не будет. Разницу понимаешь?
Еще весело, наверное, в субд типа оракла, когда у тебя переменные не выделяются из общей массы идентификаторов, и при добавлении новой колонки в базу, названия могут случайно совпасть. При этом юнит-тест может и не сломается, просто код перестанет работать правильно. Опять срубили проблем на ровном месте
Второй момент - знакомство нового человека с базой. Очень, знаешь, весело разбираться во взаимосвязи данных, когда приходится мышкой наводить на каждое поле, чтобы подсветилось, в какой таблице данные лежат. Это хорошо еще, если IDE показывает, что далеко не всегда бывает (голая SSMS, скажем, подсвечивает только тип). А если это временная таблица, которая еще и создается в другой процедуре - вообще супер
Можно еще аргументы придумать, но этих уже достаточно
По поводу читаемости vs уродские сокращения. Согласен, не очень красиво выглядит, зато читать намного проще. Особенно, если у тебя названия таблиц разной длины. 2-5 буквенные алиасы намного удобнее полных названий таблиц, уж поверь
но скажем poh для PurchaseOrderHeader - вполне себе информативно, и не мешает читать.Почему poh, а не header?
может хедер я бы и написал, зависит от многого. А так - это просто пример был, как можно сократить название таблицы до понятного алиаса. Вообще, в крупных конторах есть специальные правила по наименованию алиасов
кстати в той ссылке на стековерфлоу об этом и написано:
when the table name is unreasonably long and unreasonable due to circumstances beyond your control - and then the alias should still be something readable and logical. E.g. "EmployeeTableIndexedByUIDSourcedFromHR" can and usually should be aliases as "Employee", but not as "E"
http://stackoverflow.com/a/3718800/2724979
Я читал. Насчет длины названия - дело вкуса, конечно, но в итоге полные названия приводят к тяжелому восприятию списка колонок. Запомнить несколько алиасов для анализа запроса труда не составляет никакого (это я к тому, что по той же ссылке аргумент, что надо листать туда-сюда постоянно, что отвлекает - так вот, не надо: cначала прочитал секцию from, потом остальной запрос)
Это, в том числе, еще и интеграция с другими системами. И если сторонний разработчик вдруг добавит поле с таким же названием, у тебя все упадет. Да, на тестах ты это отловишь и поправишь. А если сразу писать нормально, то даже падать не будет. Разницу понимаешь?Я правильно понимают, ты описываешь ситуацию, когда к базе обращаются несколько приложений App1 и App2. Разработчик App1 добавляет колонку. Это изменение в базе деплоится на продакшен без прогона тестов App2?
Интересно, в какой отрасли такое?
Для тупых или неумеющих читать еще раз! Все тестируется!
только в твоем случае все свалится, и тебе придется код исправлять, а в моем ничего не сломается!
И я описывал немного другую ситуацию. По пунктам, чтоб таки дошло, я тебе просто это уже не раз приводил в пример
1. Есть внешняя система, БД которой доступна только на чтение.
2. Ты используешь ее в своей системе как источник данных.
3. Разработчик присылает патч на изменение СВОЕЙ базы
4. Админы его накатывают на тестовой среде и прокатывают тесты
5. У тебя все упало, ты с матом прописываешь алиасы в своем коде
6. Исправил, прогнал тесты. Может быть придется вернуться на предыдущий шаг. Если хорошо, накатываем на бой
или
5. Все прошло гладко, накатываем на бой
Какой вариант выберешь ты?
только в твоем случае все свалится, и тебе придется код исправлять, а в моем ничего не сломается!
И я описывал немного другую ситуацию. По пунктам, чтоб таки дошло, я тебе просто это уже не раз приводил в пример
1. Есть внешняя система, БД которой доступна только на чтение.
2. Ты используешь ее в своей системе как источник данных.
3. Разработчик присылает патч на изменение СВОЕЙ базы
4. Админы его накатывают на тестовой среде и прокатывают тесты
5. У тебя все упало, ты с матом прописываешь алиасы в своем коде
6. Исправил, прогнал тесты. Может быть придется вернуться на предыдущий шаг. Если хорошо, накатываем на бой
или
5. Все прошло гладко, накатываем на бой
Какой вариант выберешь ты?
Разработчик App1 добавляет колонку. Это изменение в базе деплоится на продакшен без прогона тестов App2?Во всех, если App1 и App2 - это приложения от разных компаний, работающие в одной базе
не, ну работоспособность то проверяется в любом случае. Защита от так сказать, мало ли все навернется
То есть варианты такие:
Вариант 1.
1. Ты всегда пишешь табличные префиксы для колонок. Получаешь либо poh, либо громоздкий список колонок. В итоге чтение кода требует больше усилий и времени.
2. Все прошло гладко, накатываем на бой.
Вариант 2.
1. Ты не всегда пишешь табличные префиксы. Получаешь не громоздкие запросы без poh. Чтение кода становиться легче и требует меньше времени.
2. Разработчик присылает патч на изменение СВОЕЙ базы
3. Админы его накатывают на тестовой среде и прокатывают тесты.
4. У тебя все упало, ты спокойно прописываешь префикс в места, где случился конфликт с новой колонкой. Добиваемся, чтобы тесты проходили.
5. накатываем на бой
Остается сравнить для конкретной системы затраты усилий и времени в обоих вариантах. Если добавление новой колонки, которая вызывает конфликты, является редким событием, то вариант 2 выглядит привлекательнее.
Вариант 1.
1. Ты всегда пишешь табличные префиксы для колонок. Получаешь либо poh, либо громоздкий список колонок. В итоге чтение кода требует больше усилий и времени.
2. Все прошло гладко, накатываем на бой.
Вариант 2.
1. Ты не всегда пишешь табличные префиксы. Получаешь не громоздкие запросы без poh. Чтение кода становиться легче и требует меньше времени.
2. Разработчик присылает патч на изменение СВОЕЙ базы
3. Админы его накатывают на тестовой среде и прокатывают тесты.
4. У тебя все упало, ты спокойно прописываешь префикс в места, где случился конфликт с новой колонкой. Добиваемся, чтобы тесты проходили.
5. накатываем на бой
Остается сравнить для конкретной системы затраты усилий и времени в обоих вариантах. Если добавление новой колонки, которая вызывает конфликты, является редким событием, то вариант 2 выглядит привлекательнее.
Ты второй аргумент таки не осилил прочитать?
Если ты не знаешь, какая колонка в какой таблице, без префиксов читать ОЧЕНЬ тяжело. Т.е. все, что ты тут написал - бред
PS: Нашел подпись контры специально
---
"дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
Если ты не знаешь, какая колонка в какой таблице, без префиксов читать ОЧЕНЬ тяжело. Т.е. все, что ты тут написал - бред
PS: Нашел подпись контры специально
---
"дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
Ты второй аргумент таки не осилил прочитать?т.е. аргументу в защиту первого пункта у тебя кончились?
ты о чем?
ты о чем?О том,что время на: тесты упали/пофиксили. Может покрываться получаемыми плюсами.
Еще раз повторю. Если есть жесткое правило: всегда пишем табличные префиксы, то нам приходится выбирать из двух плохих вариантов:
1. poh,
2. громоздкий список столбцов.
А так у нас появляется третий вариант
3. иногда опускать табличный индекс.
без префиксов читать ОЧЕНЬ тяжело
Короткие префиксы (poh) забивают дорогую кратковременную память.
Длинные смотрятся громоздко.
Наведение мышки для случаев, когда названия столбца недостаточно, довольно разумный выбор.
да, и я думаю, очевидно, что я за короткие понятные алиасы
опускать алиас/название таблицы - зло, если ты еще не понял, почему, то я сдаюсь
Наводить мышкой в запросе из 20 колонок - ну что ж, твое дело. А если у тебя 200 колонок (и не надо говорить "где ты такие таблицы берешь" - часто бывает)?
опускать алиас/название таблицы - зло, если ты еще не понял, почему, то я сдаюсь
Наводить мышкой в запросе из 20 колонок - ну что ж, твое дело. А если у тебя 200 колонок (и не надо говорить "где ты такие таблицы берешь" - часто бывает)?
к тяжелому восприятию списка колонокРассмотрим список колонок в конечном SELECT. В коде показано, что некоторые колонки выводятся напрямую в результат, а некоторые через AS
SELECT a, b AS c, d, e AS f
vs
SELECT t1.a, t2.b AS c, t3.d, t1.e AS f
Названия a, c, d, f уходят в результат запроса, поэтому каждое из этих имен является понятным без префикса.
Получаем, что сравнивать надо только понятность
b AS c
vs
t2.b AS c
Как указано выше, "c" является понятным названием, поэтому, что такое b, тоже понятно из записи "b AS c".
Получается "t2." тут не нужна для понимания названия b.
SELECT a, b AS c, d, e AS f from tbl1 cross join tbl2
а теперь скажи, какой таблице какая колонка принадлежит
Базу ты видишь в первый раз, бизнес-процессы не знаешь, поэтому названия тебе мало о чем говорят
а теперь скажи, какой таблице какая колонка принадлежит
Базу ты видишь в первый раз, бизнес-процессы не знаешь, поэтому названия тебе мало о чем говорят
а теперь скажи, какой таблице какая колонка принадлежит
Надо начинать раньше. Зачем мне ответ на этот вопрос?
Короткие префиксы (poh) забивают дорогую кратковременную память.
Конечно же нет. Тебе не нужно помнить что poh это PurchaseOrderHeader, тебе нужно помнить что poh, это {определение PurchaseOrderHeader}.
Так ты экономишь 16 символов временной памяти.
Как указано выше, "c" является понятным названием, поэтому, что такое b, тоже понятно из записи "b AS c".
Manager_id as "Manger ID"
Это вот какой менеджер проекта или отдела? А если нужен был другой ты это как поймёшь?
Manager_id as "Manger ID"Как читать код клиентов этого запроса? Там будет
Это вот какой менеджер проекта или отдела? А если нужен был другой ты это как поймёшь?
dataReader["Manger ID"]
Лезть каждый раз в запрос, смотреть краткий алиас, и искать его определение? А ты говорил, что листать не надо, тут не только листать, сначала запрос надо найти, а потом листать. Почему бы не написать:
ManagerId AS ProjectMangerId
?
Точнее даже так. Твой MangerID уйдет json-ом на клиента, и там по js коду будет разбросано MangerID. И попробуй снавигируйся на запрос откуда это всё пошло, найди алиас и т.д., сколько телодвижений, чтобы ответить на вопрос проект это или отдел?
> И попробуй снавигируйся ... сколько телодвижений ...
А я всё думал, сколько же шагов остаётся до сведения к ControllableQuery и IDE.
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
А я всё думал, сколько же шагов остаётся до сведения к ControllableQuery и IDE.
---
"Дебилы, несмотря на замедленность и конкретность мышления,
низкий уровень суждений, узкий кругозор, бедный запас слов
и слабую память, способны к приобретению некоторых знаний
и профессиональных навыков."
По факту ты предлагаешь писать длинные синонимы таблицы, только не справа, а слева.
Имеем все минусы не писания алиасов + минусы писания длинных алисов.
Имеем все минусы не писания алиасов + минусы писания длинных алисов.
ControllableQueryэтот тред не о нем
По факту ты предлагаешь писать длинные синонимы таблицы, только не справа, а слева.Странное заключение. Высосанное из пальца.
Вариант 2.Давай реальный вариант:
1. Ты не всегда пишешь табличные префиксы. Получаешь не громоздкие запросы без poh. Чтение кода становиться легче и требует меньше времени.
2. Разработчик присылает патч на изменение СВОЕЙ базы
3. Админы его накатывают на тестовой среде и прокатывают тесты.
4. У тебя все упало, ты спокойно прописываешь префикс в места, где случился конфликт с новой колонкой. Добиваемся, чтобы тесты проходили.
5. накатываем на бой
1. Ты не всегда пишешь табличные префиксы. Получаешь не громоздкие запросы без poh. Чтение кода становиться легче и требует меньше времени.
2. Разработчик присылает патч на изменение СВОЕЙ базы
3. Админы его накатывают на тестовой среде и прокатывают тесты СВОЕГО приложения.
4. Интеграционные тесты с нижестоящими приложениями не проводятся, ведь проводилось только расширение модели. Полная обратная совместимость по старым полям.
5. Админы накатывает патч на Бой.
6. В течении следующего месяца мы ловим падающие приложения 'ов.
7. У отделка кадров появляется головная боль: как уволить всех этих чудоразработчиков? по ТК это сделать крайне трудно.
я об этом спросил N постов назад
4. Интеграционные тесты с нижестоящими приложениями не проводятся, ведь проводилось только расширение модели. Полная обратная совместимость по старым полям.Для какой отрасли делаешь приложения?
5. Админы накатывает патч на Бой.
Для какой отрасли делаешь приложения?Банки.
Что бы тебе было понятнее: ты когда новую версию ControllableQuerry выпускаешь проходишь по всем командам которые её используют что бы убедиться что новая версия будет у них работать?
кстати, для интеграции вьюшки используют
кстати, для интеграции вьюшки используютТо есть ты выпускаешь кастомную версию ControllableQuery для каждой команды которая его использует? И все их поддерживаешь.
Хотя точнее будет так: в монолитной библиотеке ControllableQuery каждая функция/процедура/интерфейс дублируется под каждый проект который её использует.
А если появляется новый проект, то срочно выпускается новая версия библиотеки. С копией наборов вызова под него.
А если появляется новый проект, то срочно выпускается новая версия библиотеки. С копией наборов вызова под него.
Что бы тебе было понятнее: ты когда новую версию ControllableQuerry выпускаешь проходишь по всем командам которые её используют что бы убедиться что новая версия будет у них работать?В .NET с этим просто. Помечаешь устаревшие элементы кода как Obsolete. Пользователи, которые обновят версию получат ворнинги на этапе компиляции. К новой версии прилагается документация с пояснением что поменялось и как реагировать на эти ворнинги.
А вот какой-нибудь JQuery UI меняют название метода, и через неделю выясняется, что у тебя отвалилась редкая фича, со странными симптомами.
Кстати, приложение App2 само может запускать свои тесты (на интегрейшене обнаружив новую версию базы.
Помечаешь устаревшие элементы кода как Obsolete.Так нет устаревших элементов, только новые.
Пользователи, которые обновят
Как ты понимаешь тут разительное отличие БД от библиотеки. БД будет у всех одна.
Кстати, приложение App2 само может запускать свои тесты, обнаружив новую версию базы.
Не очень понимаю как тебе это поможет.
Не очень понимаю как тебе это поможет.Изменение базы не дойдет до продакшена, админам придет емайл, что App2 отвалилось, когда они накатили новую версию базы на тестовом энваременте.
Как ты понимаешь тут разительное отличие БД от библиотеки. БД будет у всех одна.Так что давай считать что каким-то образом у всех твоих пользователей принудительно будет тоже одна версия библиотеки.
Как ты поступишь при добавлении нового интерфейса? обойдёшь всех пользователей и заставишь прогнать unit-тесты? Будешь держать отдельный набор вызовов под каждого пользователя?
тесты с нижестоящими приложениями не проводятся, ведь проводилось только расширение моделикто дает зуб, что "только расширение модели"? Девелоперы что-то комитили месяц в репозетарий, выходит новый релиз, кто скажет расширение там или изменение в модели?
Т.е. вместо того что бы написать алиас ты хочешь закодить огромный дополнительный функционал?
Это несчитая того что должна быть среда где стоят, работают и интегрированы все приложения.
Это несчитая того что должна быть среда где стоят, работают и интегрированы все приложения.
Т.е. вместо того что бы написать алиас ты хочешь закодить огромный дополнительный функционал?Автоматизированное тестирование и так должно быть. Мы разбираем всего лишь небольшой частный случай его применения.
Это несчитая того что должна быть среда где стоят, работают и интегрированы все приложения.
кто дает зуб, что "только расширение модели"?QA даёт зуб что в экспортной схеме только расширение.
Что бы тебе было понятнее: ты внутри своей библиотеки может что-то и менял, но все старые интерфейсы работают как прежде, это QA проверил.
Автоматизированное тестирование и так должно быть. Мы разбираем всего лишь небольшой частный случай его применения.Ну то есть со своей новой версией библиотеки ты пойдёшь ко всем кто её использует?
Ну то есть со своей новой версией библиотеки ты пойдёшь ко всем кто её использует?Не я, а тесты запустятся сами.
запустятся сами.У кого-то тесты обвалились: "Спасибо, , мы включили доработку своей системы под ваш новый функционал в план на 2015 год.".
Твои действия?
QA даёт зуб что в экспортной схеме только расширение.QA глазами просматривает дельта скрипт?
QA глазами просматривает дельта скрипт?Ты правда не знаешь других методов сравнить структуру объектов?
Ты правда не знаешь других методов сравнить структуру объектов?Ну хорошо переформулирую вопрос. Каково участие в этом QA (человека)? Это одна кнопка, которая выдает — расширение или изменение модели?
Можно ссылку на такую тулзу?
В общем я сливаюсь.
Не пиши алиасы, старайся писать select *, повышай coupling.
Все разработчики в организации должны жить дружной семьёй — один что-то добавил, пусть все узнают!
Не пиши алиасы, старайся писать select *, повышай coupling.
Все разработчики в организации должны жить дружной семьёй — один что-то добавил, пусть все узнают!
Не пиши алиасы, старайся писать select *, повышай coupling.Типа это косяк SQL, что он разрешает не использовать табличные префиксы для колонок, вы так к этому относитесь?
я к этому отношусь как к дефекту девелоперов модели . Это удобно использовать при разработке/тестировании/разовых запросах, но недопустимо в продакшне.
PS Шурик, который Шурик, а не , предлагаю забить на этот тред, CQ и ее порождения - это гидра, и так просто ее не победить, смысла тратить время не вижу, я пытался - не получилось
PPS Excelsior!
PS Шурик, который Шурик, а не , предлагаю забить на этот тред, CQ и ее порождения - это гидра, и так просто ее не победить, смысла тратить время не вижу, я пытался - не получилось
PPS Excelsior!
Напоследок пример из реальной жизни. Все имена таблиц изменены.
Мы работаем в Gamedev и продаем чужие игры на российском рынке. Это означает, что мы покупаем право запускать игру на своих серверах и иметь с этого бабло. Однако это еще и требует от нас некоторых усилий. Так, если разработчик игры требует установить патч, мы обязаны установить его в срок, скажем, от 6 часов до недели (в зависимости от важности. точных условий не знаю, но они и не важны - примерно). Так вот, считали мы некую полезную аналитику в игре, для этого сделали вьюшку. Потом с ростом объема данных это стало считаться медленнее, и пока совсем не стало тормозить, попросили добавить пару столбцов из нашей вьюшки к ним в базу. Они посмотрели и сказали - круто, действительно полезно. Будет время - добавим. Прошло несколько релизов, а добавления вроде бы не было, все считалось по-старому (нам забыли сказать). Уточнили - сказали, что уже внедрили. Ок - поменяли свои скрипты. Поля назывались так же как мы предложили, так что используй мы -style, узнали бы сразу на тестовой среде, но могли облажаться по срокам внедрения. Есть свои плюсы, конечно. А так мы поменяли уже после внедрения важного патча
Так вот, Ты правда предлагаешь просматривать весь чужой патч, при том, что изменений касающихся тебя может быть не больше 1% (а то и вообще не будет)? Для чего на это тратить время?
Мы работаем в Gamedev и продаем чужие игры на российском рынке. Это означает, что мы покупаем право запускать игру на своих серверах и иметь с этого бабло. Однако это еще и требует от нас некоторых усилий. Так, если разработчик игры требует установить патч, мы обязаны установить его в срок, скажем, от 6 часов до недели (в зависимости от важности. точных условий не знаю, но они и не важны - примерно). Так вот, считали мы некую полезную аналитику в игре, для этого сделали вьюшку. Потом с ростом объема данных это стало считаться медленнее, и пока совсем не стало тормозить, попросили добавить пару столбцов из нашей вьюшки к ним в базу. Они посмотрели и сказали - круто, действительно полезно. Будет время - добавим. Прошло несколько релизов, а добавления вроде бы не было, все считалось по-старому (нам забыли сказать). Уточнили - сказали, что уже внедрили. Ок - поменяли свои скрипты. Поля назывались так же как мы предложили, так что используй мы -style, узнали бы сразу на тестовой среде, но могли облажаться по срокам внедрения. Есть свои плюсы, конечно. А так мы поменяли уже после внедрения важного патча
Так вот, Ты правда предлагаешь просматривать весь чужой патч, при том, что изменений касающихся тебя может быть не больше 1% (а то и вообще не будет)? Для чего на это тратить время?
В этом вашем интернете никогда не поймёшь, кто прикалывается, а кто дебил. (с)
а теперь скажи, какой таблице какая колонка принадлежитНадо начинать раньше. Зачем мне ответ на этот вопрос?
извините, не удержалсяТебе, может быть, и не очевидно, но судя по всему, ты с базами почти не работаешь и просто не понимаешь спецификиКогда кончились аргументы, пошел профессиональный снобизм.
вчера как-то пропустил, а сегодня в уведомлениях об ответах увидел. Я может и сноб, но ты все равно не понимаешь спецификиты все равно не понимаешь спецификиСпецифики чего? Вашего процесса разработки? Я и не должен его понимать, потому что не знаю о нем.
Как я писал выше, моя позиция такая, что ставить префиксы или нет зависит от общей ситуации. В каких то ситуация имеет смысл ставить везде табличные префиксы. Но есть много проектов, в которых от этого только минусы.
Ты по непонятным причинам пытаешься обобщить опыт вашего процесса разработки на все процессы разработки баз данных.
Конечно, неплохо бы иметь однозначность по этому вопросу. Но если бы однозначность имела бы хорошие обоснования, то почему это не отразили в правилах самого языка SQL? Не отразили, значит, ставить префиксы или нет зависит от ситуации.
Это удобно использовать при разработке/тестировании/разовых запросах, но недопустимо в продакшне.Ага, удобно всё-таки
недопустимо в продакшне.Это когда продакшен не имеет других средств защиты от ошибок.
Честно говоря, такой продакшен (который держится только на том, что ни один из девелоперов не забыл написать табличный префикс) не вызывает доверия.
А вот если бы запрос не компилировался бы без префиксов, это было бы надежно. Кстати, к CQ такую проверку можно прикрутить. Включать или выключать ее в зависимости от ситуации на проекте.
тебе нужно помнить что poh, это {определение PurchaseOrderHeader}.Не находишь, странный какой-то язык сделали, сначала идет использование, а потом определение?
SELECT poh. ... poh. ... poh. ... FROM PurchaseOrderHeader poh
Текст человек привык читать последовательно. SQL делался именно так, чтобы запрос был похож на английский текст. Тем самым подразумевается, что читателю понятен смысл имен столбцов без poh. Читайте основы, см. статью Кодда, там изначально идет всё от столбцов (доменов а не таблиц.
pohсчитаю, это надругательство над красотой языка SQL
девелоперов модели .Вот то-то и он, люди — не машины.
угу, машина бы не забыла добавить
такой продакшен (который держится только на том, что ни один из девелоперов не забыл написать табличный префикс) не вызывает доверия.ты эльф
Оставить комментарий
6yrop
Говорят в запросах надо всегда использовать псевдонимы. Вопрос. Зачем нужны имена, если всегда используются псевдонимы?Какие правила формирования псевдонима? Например, в C# имя локальной переменной часто (но не всегда) формируется так, для типа PurchaseOrderHeader
purchaseOrderHeader или
orderHeader или
header.