Вопрос непонятен. О каком интерфейсе идет речь? В каком смысле "интерфейс должен учитывать"? Если вы об интерфейсах, которые interface в языке, то они никак не могут "учитывать", что у реализующего класса должен быть конструктор, т.к. они есть абстракция от конкретного реализующего класса.
Влад Животнев хм, спасибо, не обращал внимания. Видимо с ним поступали также, как и с html strcit/transitional - если можно не ставить, то не ставили))
AlikDex для пинга
а что за сервер-то? Это ж и от дисковой подсистемы тоже зависит. Если сервачок за 200 рублей, и железо жестко оверселлится хостером, 90мс это просто отлично.
> Как все это связывается и работает очень шустро?
Вы неправильно прикидываете скорость выполнения запроса. Всегда есть постоянные издержки, например на синтаксический разбор и построение плана. Если вы внутри приложения будете использовать prepared statements, запрос будет выполняться побыстрее. Это раз.
Два - это то, что при наличии индексов длительность выполнения запросов растет алгоритмически. Это достигается за счет использования разновидностей деревьев в индексах, например B+-дерева. Т.е. если у вас количество записей вырастет в 100 раз, время запроса ни в коем случае не должно вырасти в 100 раз, оно даже в 2 раза не должно вырасти.
А вы уверены, что хотите ссылаться на .gitignore в домашней папке? Обычно он коммитится, чтобы с ним работали остальные разработчики, да и хотя бы потому, что файлы для игнора зависят от содержимого репозитория (если у меня проект IDEA, то и папка там будет соответствующая, если проект Студии - то и .vs я туда добавлю).
apreobr смысл картинок одинаковый - я хочу зарезервировать N единиц какого-то ресурса и совсем-совсем ограничить к нему доступ.
Скидку мы и так делаем, т.к. пытаемся что-то дельное посоветовать. Многие ограничились фразой "Бред какой-то", и их можно понять. Я в принципе тоже мало что могу посоветовать, т.к. в вопросе полностью отсутствует отсылка к принципам современных ОС, и непонятно, что конкретно автора не устраивает, и почему.
Kirill Frolov Ставьте диалоговому окну объект PersonViewModel в качестве контекста данных и сделайте правильные привязки контролов диалогового окна к свойствам PersonViewModel
соглашусь, автору вопроса надо сначала подумать, надо ли оно ему вообще). Особенно подозрительно, что нет ни слова о том, что нужна кусок физической памяти (а если бы человек понимал, что пишет, он бы обязательно это указал, как и причину такого необычного требования).
Евгений например, избавиться от супер-инклудов, которые попадают в слишком много cpp-шников и при изменении в них надо пересобирать почти весь проект. Иногда такие инклуды возникают по недосмотру. Или из-за лени.
Flaker
> "property" — в данном случае, я называю дом/квартиру/участок (Недвижимость), а не свойство.
> "characteristic" — это характеристика недвижимости (property)
Вот это поворот)) Хорошо что сказали.
> а значения будем хранить вместе с "property", не будет ли это, по сути, реляционной структурой?
у реляционной структуры есть схема. У всех кортежей одного отношения схема одинакова по определению, иначе быть не может. У вас же в каждом документе может быть свой набор характеристик для entity. Даже если данные о САМИХ характеристиках соберете где-то еще (например, их отображаемое название), это не значит, что каждая конкретная характеристика должна встречаться в каждом документе - это вам и нужно, как я понимаю.
Дошло до меня, "property" это "собственность" что-ли?)) Почему не estate - недвижимость?)
Flaker если вам пока не понятно, опишите задачу еще раз максимально просто (разжуйте, что для вас "свойство" и "характеристика", и какие они бывают), а я приведу вам пример того, что предлагаю хранить.
> 1) Все характиристики лежат внутри property. Для каждого property свой набор характеристик, не связанных с другими наборами характеристик.
вообще не понял смысл этого утверждения. я предлагаю очень просто: для каждого дома у вас JSON-документ (неважно - документ ли в это в Монге, или же значение колонки Properties в таблице), в этом документе у вас по одному ключу для каждой характеристики. Чтобы не было проблемы "переименования" характеристики, можете отдельно хранить отображаемое название, чтобы его менять (чтобы не менять все документы).
Честно говоря совсем не понял вашу таблицу "характеристики свойств". Если у вас стоит проблема типа хранимого значения, то с JSON-ом ее не будет по определению.
В общем и целом я не вижу у вас схемы как таковой. Для меня логично в этой ситуации работать с полуструктурированными данными (XML или JSON особого значения не имеет, хотя последний подходит чаще).
