А как сейчас с работой?
Это хоть нормальный вопрос. Тут хоть мурр и начал, как всегда, выделываться, разночтений в ответе не будет.Меня как-то спросили что в селект быстрее отработает, а!=123 или a<123 and а>123, если а индексируется. Понятно что ожидали ответ, мол, так как индекс бинарное дерево, то меньше-больше отработает быстрее. Но индексы можно и как хэш делать, тогда != ощутимо быстрее. Про это народ не подумал-с.
Это был собес на DBA?
Я знаю, почему АлексНек не принимает участие в дискуссии. Он не знает ни чем джойн от юнион отличается, ни что отработает быстрее - "не равно" или "меньше-больше". И ему стыдно.
))
выделываться
-----
Нее, это не выделывать...
Выделываться - это когда УЖЕ принято (мною) решение по шараге,
задать вопрос спящему на собесе ДБА, при том что спрашивали больше ДБАшные вопросы на ДотНетовской позиции:
- А как быстрее всего будет очистить большую (сотни лямов строк) таблицу с индексами, но без реляций?
После чего остановить ломанувшегося на помощь товарища пояснением:
- Я понимаю, по вашим вопросам, что вам нужен кто-то в помощь вашему ДБА, и что вы помогаете, насколько можете, но мне сейчас нужно хоть как-то оценить насколько сложно будет с вашим ДБА работать, по-этому желательно получить ответ именно от ДБА...
Вот это - да, выделываться... а тут - пустяки, просто акцентировал внимание на точности формулировки...
primary and foreign keys
-----
Любимая нособойка?
Помнится было такое.
Дана документация на базу. База планировалась оракловская, но в текущей имплементации использовалась мелкомягкая.
В документации для одной из таблиц написано
- поле первичного ключа заполняется триггером из последовательности.
У мелкомягких, как ты должен помнить, триггеры - есть, последовательностей - нет. Кроме этого возможность заполнить поле первичного ключа в триггере практически отсутствует в виду его а.) автоинкрементности, б.) наличия конкурентности, а если говорить об ЕФ5, то и недоступна (из-за ошибки).
Ну и как ситуацию размотаешь?
- А как быстрее всего будет очистить большую (сотни лямов строк) таблицу с индексами, но без реляций?
Кстати, я всегда думал, что там что-то типа очистки диска при удалении файлов - т.е. ничего не самом деле не очищается, а просто эти данные разрешается перезаписывать. Реальное стирание занимает столько же времени, как и запись. Ну и типа в таблице - тупо обнулить индекс, обозначить, что в таблице ноль данных, и позволить писать данные снова. А как там и куда старые данные денутся - не моё дело. Просто СУБД обозначит их как "по ним сверху можно писать". Нет?
а если говорить об ЕФ5, то и недоступна (из-за ошибки).
Ну и как ситуацию размотаешь?
Перейду на ЕФ6, 7 и т.д., где всё поправили. А пока вкорячу обходной костыль. Не отказываться же ото всех плюшек ЕФ из-за того, что там какой-то фичи нет или не работает.
Вчера ездил в Лимерик... по необходимости... т.е. - со сранья, ко времени, весь на бегу, полный день и только поздно вечером совершенно убитый добираюсь домой...
Где-то в обед позвонили и говорят
- Нашли ваше резюме в нашей базе резюме и хотим предложить что-то.
- Вообще-то, в прошлом месяце Я уже имел интервью в вашей компании.
(мне интервью не понравилось настолько, что повторное не интересует - это про себя).
- О, да, но это другой департамент. Нам нужно тыгыдым-тыгыдым-тыгыдым...
- Я не ищу позицию менеджера, Я делаю только работу программиста.
- Я вам пришлю спецификацию на позицию?
- Да, присылайте без проблем.
Вечером, уже по окончании рабочего времени, получил нечто... то ли драфт, то ли поток сознания выплеснулся...
Все в цвете и почеркано. 5 страниц требований.
Прочитал... кого именно и зачем ищут - непонятно... что-то между Архитектором, ПМ и извлекателем тех.заданий,
паблик-релейшаном и еще кем-то кого я не знаю как назвать.
Усталая голова не смогла выстроить что-то понимабельное - взял паузу на обдумывание...
А сегодня в 11-ть в почте:
Any further thoughts on this position as I know the hiring manager is keen to interview you.
Ну а в почту Я заглянул только сейчас... 
п.с. А чего с таким делать? Организация из тех, которые сейчас будет мотать как листья на осине в бурю. А осина - довольно хрупкая... И даже если выживут - нервы помотают бай боже...
ничего не самом деле не очищается
-----
На самом деле - очищается.
Правда не то, что ты думаешь.
Не переживай - на сегодня, наверное, нет того, кто знает что именно очищается в каждой из существующих ФС.
Я более-менее в деталях знаю штуки три, а остальные даже не планирую смотреть...
обозначить, что в таблице ноль данных
-----
Ну и какой SQL-командой ты это сделаешь?
Не переживай - на сегодня, наверное, нет того, кто знает что именно очищается в каждой из существующих ФС.
Я более-менее в деталях знаю штуки три, а остальные даже не планирую смотреть...
Я вы уверены, что в этих трёх штуках за время ничего не поменялось, как они там очищают внутри? Постоянно отслеживаете их изменения?
обозначить, что в таблице ноль данных
-----
Ну и какой SQL-командой ты это сделаешь?
Если у таблы нет связей с другими таблами, то проще дропнуть и создать заново. Если есть... то тоже дропнуть, и создать заново со связями.
Меня вообще удивляет, что нет какого-то простого механизма избавиться от кучи данных и связей.
А пока вкорячу обходной костыль.
-----
А после костыля база будет соответствовать документации?
Зависит от базы. В крайнем случае я могу не маппить проблемные места через ЕФ, а обработать их голым скулем. В остальных местах пользоваться удобством ЕФ.
В документации для одной из таблиц написано
- поле первичного ключа заполняется триггером из последовательности
У мелкомягких, как ты должен помнить, триггеры - есть, последовательностей - нет. Кроме этого возможность заполнить поле первичного ключа в триггере практически отсутствует в виду его а.) автоинкрементности, б.) наличия конкурентности, а если говорить об ЕФ5, то и недоступна (из-за ошибки).
Что тут думать? При переходе на MS SQL предупреждаешь заказчика, что поле будет заполнятся не триггером, а через Autoincrement.
Не помню, чтобы EF 5 имел с этим сложности.
Нее, это не выделывать...
Выделываться это нести чушь, никаким образом не относящуюся к вопросу, но демонстрирующую необозреваемость ширины опыта. Вроде
Кроме того что они разные, они бывают еще и не имплементированные, и имплементированные с ошибками.
Мне, например, довольно регулярно попадались юнионы, отрабатывающие как юнион алл....
Что влияет на разницу между join и union чуть более чем никак.
Или тебе попадались union-ы которые декартово произведение таблиц выдавали? Делаешь этак юнион по двум селектам, каждый на 10 результатов, а оно как хреняк - и больше 20 результатов, все таблицы из селектов перемножил, да?
А как быстрее всего будет очистить большую (сотни лямов строк) таблицу с индексами, но без реляций?
В смысле drop и create заново? И DBA на это не ответил?
предупреждаешь заказчика
------
А ты знаешь кто заказчик?
Тебе для того и дали настолько подробную документацию, чтобы было сделано точно как требуется.
поле будет заполнятся не триггером
-----
А в документации написано - триггером.
Зачем - не знаю, но заказано - именно триггером.
Из того что могу предположить - чем-то внешним перехватывается срабатывание триггера и делается что-то, что не отражено в документации на базу.
Так что твое предупреждение... хммм... в общем у заказчика так работать не будет.
Решение, кстати, предложили довольно изящное - добавить поле автоинкрементного ключа как последовательность и переписывать его триггером в требуемое поле. Все требования удовлетворены и соответствуют документации. 
а оно как хреняк - и больше 20 результатов
-----
Вот именно так оно и было. Почему - не помню - очень давно было.
union-ы которые декартово
-----
Ну таких вариантов не видел, а вот некорректные варианты как джойнов, так и юнионов - это пожалуйста...
таблицы из селектов перемножил
-----
Помнится как-то закомментрировал строку в условиях джойна и получил что-то похожее... по крайней мере на уровне ощущений... 
Тебе для того и дали настолько подробную документацию, чтобы было сделано точно как требуется.
Дока, заточенная на одну конкретную СУБД? Либо заказчик подвигается по требованиям, либо идёт к тому, кто делает именно с этой СУБД.
поле будет заполнятся не триггером
-----
А в документации написано - триггером.
Зачем - не знаю, но заказано - именно триггером.
Из того что могу предположить - чем-то внешним перехватывается срабатывание триггера и делается что-то, что не отражено в документации на базу.
Так что твое предупреждение... хммм... в общем у заказчика так работать не будет.
А может быть, что ваши предположения неправильные? Тут разговаривать надо с заказчиком, а не сразу бросаться выполнять все требования. И может даже дать посмотреть, действительно ли "перехватывается триггер".
Когда не дают смотреть, а задача представляет из себя чёрный ящик с кучей странных требований, которые не ложаться нормально ни на одну СУБД или не на один фреймворк, то результирующий код на обслугу такого ящика обычного представляет из себя лютое дерьмо на костылях, конвертерах и прочих подгонках. Потом эти костыли так же отправляются в этот чёрный ящик, а следующему подрядчику выкатываются ещё более идиотские и странные требования - учитывающие костыли предыдущих наработок.
Если есть... то...
------
...не получится - не дадут дропать пока реляции не пусты.
то проще дропнуть и создать
-----
И таки - да, это самый быстрый способ.
При условии, что база в монопольном режиме. Иначе лок можешь поймать.
Вариант не без недостатков - частности потом тайауты полезут - но в рамках поставленных условий - годный.
А вопрос по таймаутам идет вторым - Какие проблемы и почему надо ожидать после пересоздания таблицы?
В принципе, этих двух вопросов... точнее - развернутых, в меру понимания проблем, ответов на них достаточно чтобы оценить ДБА.
А джойны с юнинами - там и кодеры справятся...
Постоянно отслеживаете
------
Они - стабильны. И используются уже очень давно. Кое-что аж с 70-х...