Боюсь, что никак. Вот тут предложили переназначить русские клавиши один раз и навсегда.
Но! Этот способ не работает, так как самые важные сочетания, где участвуют : ; ^ [ не переназначатся.
Я не поленился и перепробовал остальные расширения (все, наверное), но у всех та же беда остаётся. Увы :-(
Блестяще! Немного углубился в эту тему - оценил плюсы и минусы и понял, что это то, что нужно.
Лично для меня из минусов вижу только трудность перехода между PostgreSQL и MS SQL, где этих перечислений, фактически, нет. Но может быть оно и к лучшему? Может быть вообще уйдём от MS SQL.
А как правильно с таким подходом в коде дёргать значения? Например, у документа четыре статуса: открыт, выпущен, закрыт и зарегистрирован. В таблице им соответствуют 4 числа, но это не обязательно 1, 2, 3 и 4. Порядок тоже может быть не хронологическим. Сейчас я чаще вижу в коде именованные константы с понятными именами: OPEN, RELEASED, CLOSED и т. п. Но всё это сильно смахивает на вариант №3 - константы в коде дублируют данные из таблиц и при их изменении приходится этот код менять.
Армянское Радио, ужас. Не хотелось бы с такой таблицей работать :-)
Но ситуации разные бывают. Например, в том же Navision много таблиц создать нельзя - запрещает лицензия. Там в прямом смысле приходится покупать у майкрософта право на создание новой таблицы.
Могу отметить, как эта проблема "решена" в Navision: там для полей таблиц есть специальный тип данных option, который описывается прямо при создании основной таблицы. В нём перечислены возможные варианты значений, которое может принимать это поле.
Другой вариант, завести один универсальный справочник структуры:
source_table
source_field
key
value
В ней может поместиться весь зоопарк справочников. Но как к ней тогда организовать внешние ключи? Без них будет нарушена целостность данных.
Владимир Коротенко, кстати, а замечательная библиотека. Конкретно здесь я её, скорее всего, уже использовать не буду, но кое-где ещё она мне подходит. Спасибо!
SSRS Builder по видео не совсем для той задачи. Там и встроенный редактор, который из отчёта чуть ли не презентацию позволит сделать. Также есть возможность напрямую SQL писать, когда нужно, но это не для моих пользователей.
Excel уже умеет данные из БД подтягивать? У меня Calc, даже не слежу за его развитием. Опять же, если без шуток - фильтры в нём хороши и удобны, а объединение связанных таблиц как-то не представляется.
Что за Power BI - сейчас посмотрю.
Наши требования куда скромнее - пользователь хочет себе получить табличку, не больше. Понатыкать галочками те колонки, которые ему интересны и ни строчки SQL. Иначе и правда проще мне репозиторий отчётов самому накидать.
Не переживайте - вопрос решён единогласно. Лично мне - программисту - эта функциональность не нужна. Это именно пользователям.
Никакого программирования для пользователей там нет - только мышкой галочки отмечать.
ThunderCat, спасибо, учту.
В том-то и проблема, что:
- "если не перестанете расти"
- "то через какое-то сравнительно небольшое время"
не всегда работает. Многие разработчики не могут самостоятельно перепрыгнуть определённую планку ввиду отсутствия критики от других разработчиков. Я как раз из таких.
По цене - да, уже оценил и понял, что не зря решил оценить только архитектуру. :-)
Да, я знаю, что PHP для программирования станков ЧПУ и тому подобных не применяют. На это нашлись причины, теперь успокаиваю себя тем, что в общих чертах PHP - это язык общего назначения, а потому можно :-)
Я отредактировал и переформулировал вопрос, так как он и правда оказался двусмысленным и был неверно понят.
Я - не заказчик. Я и есть разработчик этого ПО. Движет мной желание саморазвития, ибо коллег у меня, имеющих возможность оценить, нет. Я тут один и за архитектора, и за аналитика, и программиста и т.п. Работодателя этот вопрос вообще не интересует.
В представлении так:
В модели поиска (в той, где условная функция search()) это: