Обновить
25
ApeCoder@ApeCoder

Разработчик

0,1
Рейтинг
6
Подписчики
Отправить сообщение
Мне бы хотелось максимально абстрагироваться от хранилища. Идеально строить объектную модель предметной области (хоть и с небольшой оглядкой на модель хранения) а затем чтобы ORM брало на себя весь меппинг, как структурный так и поведенческий.
1) Я предлагаю рассмотреть такую задачу. Так как у нас ORM а не что-то еще.
2) Что там с построением индексов?
3) Мне опыт подсказывает другое, но возможно у нас с вами разный опыт.
1. Я имею ввиду в рассматриваемой задаче нет. Есть объектная модель — не важно как получена, надо построить реляционную базу по ней.

2. Есть ли правила по которым проектировщик строит базу в зависимости от объектной модели и нельзя ли закодировать эти правила?

3. В каждом сложном UI есть простые куски.
Вероятно надо несколько опуститься: нет никакой предметной области, есть объектная модель. Вопрос в том, может ли ORM получив некоторую дополнительную информацию об объектной модели в терминах этой модели создать индексы или мы обречены командовать ORM в терминах хранилища. А так же можно ли использовать ту же самую информацию в других местах: например при генерации UI опускать создание контролов для фильтрации если у нас мало элементов в коллекции и, наоборот, предлагать фильтрацию по умолчанию по важным признакам.
Это не хинт «создай индекс» это описание свойств «это сочетание атрибутов для меня важно в смысле поиска»
Я думаю, что этот принцип — недостижимый идеал, к которому, тем не менее, надо стремиться.
Совершенно согласен. Любая реализация объектной модели несет в себе следы ограничений ее интепретатора. Будь то JIT или SQL. Соответственно мы должны как-то сообщить интерпретатору что данном случае мы от него ожидаем. Например что запросы по определенным атрибутам нам представляются наиболее важными (а это уже требование из предметной области, как мне представляется)
Тогда невозможно построить индекс в принципе, не важно на каком уровне его декларировать — БД или приложения
Мне кажется, что есть что-то в предметной области, что ORM может отмепить на индексы. Например, сделать какие-нибудь «хинты» типа «Типичный размер этой коллекции порядка десятков тысяч» и «нас интересуют быстрые выборки по вот этому сочетанию атрибутов». Теоретически ORM может при меппинге сгенерировать соответствующие индексы.
Это надо коптером забраться над целью, а там может быть, например, крыша. Планирование практически бесшумно и наверняка быстрее чем наводить коптер. Интересно, насколько управляющая электроника может сделать точной планирующую бомбу при падении.
Коптером поднимать на большую высоту набор планирующих умных бомб и сбрасывать по крутой траектории. Еще бомбы можно сделать химическими
А есть где-нибудь статья про это (как и кем осуществлялось, как оформлялось, по каким источникам известно о существовании квот и т.д.)
Не вижу причин не деталь так же на питоне — подогнать блок табом до нужного количества отступов и какой-нибудь форматтер типа github.com/google/yapf
Я не работал с IDE на Python — в pycharm, судя по описанию , есть автоформатирование.

Я не вижу теоретических препятствий к тому, чтобы работало как в C++ только сначала подогнать блок табом под нужый уровень вложености. Насколько я знаю есть и реформат при вставке:

Reformat on paste Use this drop-down list to specify how to place pasted code blocks. The available options are: – None — The pasted code is inserted at the caret location as plain text without any reformatting or indenting.
– Indent Block — The pasted code block is positioned at the proper indentation level, according to the current Code Style Settings, but its inner structure is not changed.
– Indent Each Line- Each line of the pasted code block is positioned at the proper indentation level, according to the current Code Style Settings.
– Reformat Block- The pasted code block is reformatted according to the current Code Style Settings.
Ок давайте использовать термин «обход контейнера»
A fixed-size table (or array) is usually not considered a collection because it holds a fixed number of items, although tables/arrays commonly play a role in the implementation of collections. Variable-sized arrays are generally considered collections, and fixed-size arrays may likewise considered a collection, albeit with limitations


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


И это нормально — кусок который не всегда будет выполняться будет выглядеть вложенным и отделен от остального. В конец итерации цикла всегда можно будет вставить кусок кода, который будет гарантированно выполняться. Рассуждать про свойства цикла будет проще.
Надо называть не done, а более конкретно:

while(!found && I.moveNext())
{
    ...
    Found = ...
    If(found)
    {
         ....
    }
    ...
}



Тогда понятнее смысл цикла

Информация

В рейтинге
4 840-й
Откуда
Россия
Дата рождения
Зарегистрирован
Активность