условный исходник




стоит задача создать вьюху, которая с одной стороны покажет имена компаний по id
но при этом выкинет из выдачи все запросы, которые не подходят текущему canId (ака userId)

короче и понятнее:
1) canId у всех должен или совпадать или запись выкидывается
2) companyId если совпадений не найдено, то и хрен с ним, просто рисуем пустые поля, но запись выводим

вариант 1

генерит ошибку
#1052 - Column 'canId' in from clause is ambiguous




вариант 2

генерит ошибку
#1060 - Duplicate column name 'companyId'




Как же мне зарешать подобную задачу? Может через промежуточные вьюхи?

У меня уже почти получилось решить задачу через вложенные селекты, застрял на этом.

Вот это работает



А вот это уже не работает!! Хотя я думал, что это одно и то же!



Если кто-нибудь подскажет, что я во втором случае сделал ошибочно, то исходная задача будет решена.

забыл добавить что select * from (select *) падает с ошибкой

#1060 - Duplicate column name 'companyId'

Блин, оказывается в селектах для вьюх запрещены вложенные запросы. Блин! Блин! Блин!

В итоге получилось дерьмо со списком огромных полей и для всех подзапросов пришлось создавать отдельные вьюхи, чтобы потом в итоге получить результирующую вьюху. Фиг знает как вся эта шняга будет работать внутри с точки зрения скорости.

miksoftМодератор: Оффтоп и препирательства зачищены. Прошу не возобновлять.
А ссылка - всегда актуальна. Ее можно просто не относить на свой счет. Но потом не стоит удивляться "ах, они, нехорошие люди, мне вот это не рассказали".

Я все равно для очистки совести выражу свою позицию.

1. По поводу на чей счет.

До того как она разместила ссылку общение шло между вами и мной. Никого третьего не было.
Допустим я не стану относить эту ссылку на мой счет.
Тогда получается, её ссылка относится к вам.
Она что модератора у которого >27К сообщений в такой чванной форме будет учить как формулировать свои мысли на форуме???

2. Про актуальность ссылки

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

Петя назвал Сашу бараном? Нет, не назвал. Петя лишь сообщил, что у него есть такой принцип, не сообщать время тупым баранам. Но из контекста получается, что он Сашу все таки за тупого барана считает.
Так и её ссылкой получилось.
Да, её ссылка хорошая и верная.
Но будучи помещенной в контекст. Да ещё и без комментариев она сыграла именно роль оскорбления.

3. Правила для лохов

Прежде, чем требовать исполнения каких-то правил, то ей сначала самой придется эти правила исполнять. Если же она требует исполнения каких-то правил, а сама их при этом нарушает, то эти правила считаются правилами для лохов. Если например, кто-то требует прекратить курить, а сам при этом курит, значит правило о запрете курения создано для лохов.

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

Cygapb-007да, в третий раз скажу

Да можете хоть в пятый, хоть в десятый сказать, задача-то решена! И она решена с помощью перечисления полей по массиву, в котором оставлены только уникальные значения. Это решение стало возможным за счет того, что по кодстайлу имена полей содержат префиксы таблиц company (companyId, companyTit) вместо company(id, tit) как обычно. Решение на алисах не подходит, потому что вся эта шняга генерится автоматически, а результаты потом автоматически же становятся полями внутри программного кода.

Cygapb-007И читайте ответы, а то как-то даже неудобно... говорят человеку, а он как будто не видит..

А с чего вы взяли, что я их не читал??? Что касается обсуждения, то после того как Акина в жесткой форме намекнула, что я тупой и не в состоянии сформулировать свои задачи, у меня пропало желание что-то там обсуждать... Когда она без строчки комментария разместила свою ссылку, то она тем самым как бы сформировала контекст, в котором любое мое сообщение считалось бы высказыванием тупого идиота... поэтому прежде, чем вернуться к обсуждению предмета темы сначала пришлось устраивать скандал для защиты своей чести и достоинства.

miksoftLumixФиг знает как вся эта шняга будет работать внутри с точки зрения скорости.Это вы еще самого интересного не читали:
View Processing Algorithms MERGE cannot be used if the view contains any of the following constructs:

Aggregate functions (SUM(), MIN(), MAX(), COUNT(), and so forth)
DISTINCT
GROUP BY
HAVING
LIMIT
UNION or UNION ALL
Subquery in the select list
Refers only to literal values (in this case, there is no underlying table)Если кратко, то шансов на приличное быстродействие практически нет.

Я не до конца понял, что тут имелось ввиду.
На всякий случай проверил вариант с algorithm = temptable - от решения на промежуточных вьюх он не спасает.

Что касается скорости.
Тот тут такой вопрос.

Селекты, которые лежат в основе этих вьюх можно ведь и просто использовать в ходе самой программы. Но я сделал допущение, хотя и не знаю насколько оно верное, что если мы эти сложные селекты засунем во вьюху, а потом клиентский код будет селектить по этим вьюхам, то это получится быстрее, чем чистыми селектами.

Короче, сейчас все держится на моей гипотезе, что вьюхи - это как бы кешированные запросы и поэтому работают быстрее самих запросов.

Верно ли это предположение или нет - не знаю.

Cygapb-007Теперь вдруг выясняется, что вьюху делаете не вы, а она генерируется автоматически

Ну какая разница?? Руками я делаю вьюху или с помощью программного кода. Автор-то все равно я. Автомат может сделать только то, что я могу сделать руками, а я руками только вот так криво смог найти хоть какое-то решение.

tanglirпереписывайте шнягогенератор

Я не знаю в что его переписывать, потому что есть только одно решение и оно шнягогенератором и исполняется.

Вот что было сделано:

Исходная задача:




данная конструкция падает по след. причинам
1) дубликаты имен в точках склейки - это поля по которым таблицы клеются и поэтому они всегда равны

лечится за счет мержа списка полей и выкидывания дубликатов и включения в имена полей имен таблиц

2) дубликаты имен за пределами точек склейки - эти поля могут различаться, берется то, которое указано в направлении джоина, чаще левое, то есть берется из базы склейки, а не из припоя

лечится за счет вложенных запросов

3) вложенные запросы запрещены во вьюхах - лечится за счет промежуточных вьюх

в итоге задача была решена вот так




и вот эти v_0, v_1 ... реально бесят... в натуре какая-то шняга нездоровая получилась...
но не знаю как иначе...

miksoftВ худшем случае для каждой View при каждом выполнении всего запроса будет генериться временная таблица, у которой не будет индексов. Т.е. быстродействие катастрофически упадет. И никакого кэширования тут не будет.

Если тут вы правы, то это очень печальная новость, потому что я был уверен, что algorithm=merge заставляет вьюхи использовать те же индексы, что и у таблиц, из которых собрана вьюха!

miksoftalgorithm=merge будет использовать индексы таблиц.

Отличная новость! Именно на такое поведение вьюх я и рассчитывал.

miksoftНо на реальных боевых запросах, которые обычно обвешаны всякими "наворотами", шансов добиться именно algorithm=merge весьма немного с учетом вышепроцитированных ограничений.

В конкретно этом случае отсутствую "запросы с наворотами". Хотя не знаю какие именно навороты имеются ввиду. Все "навороты" как раз и вшиты в билдеры вьюх и все эти навороты исчерпываются несколькими типами джоинов, никаких where limit и order by.

В этом-то и прикол, что мы вшиваем под капот вьюхи некий конструктор, основанный на схеме данных, а клиентский код работает уже простыми select * from view_of_some_type, при этом в хвосте юзает только where равно, лайк, регуляник, больше, меньше, а так же order by и limit - больше ничего и получает аггрегированную запись, с которой уже делает что хочет... то есть младшим кодерам, которые пишут основное клиентское мясо нет нужны вникать во взаимосвязи справочников и журналов между собой - это соберет их старшина, а так же нет надобности вникать в систему прав доступа - все это уже зашито под капот вьюх - просто бери и работай по простому интерфейсу getData({ ... }) и не парься...

tanglirLumixникаких where limit и order byLumixа так же order by и limitВы уж как-нибудь определитесь, есть оно у вас или нет...

1) при создании вьюх никаких where нет - только джоины
2) когда клиенты по этим вьюхам выбирают селектом данные, то там есть только where, order, limit


tanglirLumixи получает аггрегированную записьэто вы намекнули о наличии group by во вьюшках или что-то другое имели в виду?

Никаких группировок нету, ни во вьюхах ни в клиентских селектах.


tanglirLumixто есть младшим кодерам, которые пишут основное клиентское мясо нет нужны вникать во взаимосвязи справочников и журналов между собой - это соберет их старшина, а так же нет надобности вникать в систему прав доступа - все это уже зашито под капот вьюх - просто бери и работай по простому интерфейсу getData({ ... }) и не парься...Это всё нормально бы работало, будь у вас в качестве субд постгрес. Или оракл. Или мсскл. Или {впишите_свой_вариант}, но не майскуль. По причинам, описанным выше.

О!))) Не хочу вас пугать, но всей этой архитектурной заманухе ещё предстоит крутиться на WebDB)))) А он вроде с sqlite форкнут.

javajdbcзадача, на самом деле, сложная, и в обшем виде решения не имеет.
Даже на Оракле с его "предикат пуш" выставление наружу
сложных вьюшек может стать проблемой:
незная сложности вьюшки -- солдаты в траншеях легко зафигачат
еше парочку жоинтов и убьют нафиг сервер.
И никакой оптимизатор не поможет.

В нашем случае клиентских джоинов вообще быть не может. Никто не даст младшим кодерам делать джоины с вьюхами. Это ловится синтаксически и если будет найдено, то автору за это будут устраиваться "анальные кары".


javajdbcАвтору топика -- ваше решение с 25-ю вложеных вьюшек,
и отдать его в трашеи -- сработает на таблицах из 10 строчек,
потом -- умрет на одном неосторожном жоинте.

Я вас попрошу раскрыть содержание термина неосторожный джоин. На данный момент у нас пока только натуральные и левые джоины и они есть только на стадии создания вьюх. На стадии использования вьюх джоинов нет (в клиентских селектах).

Что же такое неосторожный джоин и чем он отличается от осторожного?

Может вы просто пользуясь своей завышенной квалификацией пытаетесь меня напугать, внушить мне страх? :-) Бесполезно. Я очень внимательно слежу за формулировками.

javajdbcАвтору топика -- вы сами себя обделили, скрыв половину задачи
и половину граничных условий (например -- какойто левый генератор).

Я вообще не понимаю при чем тут автоматизация??? Что вы все заладили про автоматизацию??? Какая разница я вручную соберу запрос на создание вьюхи или скриптом, какая разница я вручную перечислю поля таблицы или скриптом из конфигурации схемы данных??? Это не имеет значения к решаемой задаче!

miksoftLumixWebDBЧто за зверь? поиск дает несколько вариантов...

Встроенная в бразуер база данных, которая управляется через javascript.
http://en.wikipedia.org/wiki/Web_SQL_Database

miksoftА почему отлаживаетесь на MySQL?

Потому что эта замануха должна будет работать и в браузере и на сервере тоже, а на сервере стоит mysql (правда mariaDB, если быть точным). Главное, чтобы для младших кодеров принципы работы выглядели одинаковыми, чтобы им приходилось меньше учиться и меньше думать.