Станислав Макаров

слабосвязанные данные, например новости - краткое описание новостей точнее

В общем, если нужны сложные выборки и несколько разных индексов - берите Монгу, если выборки только по одному ключу - посмотрите key-value: если вам для основного хранения (т.е. НЕ для кэша), то попробуйте Riak, если для кэширования чего-то, что уже и так есть в какой-то другой (основной) БД, то неплохо подойдет Redis.

Суть любого робота в автоматизации того, что делать руками не хочется или невыгодно. А что конкретно автоматизировать, это зависит от конкретного случая.

Примеры:

• боты для DDOS - см. определение DDOS-атаки
  
• боты для сайтов/форумов/чатов - рекламный спам, авторегистрация пользователей; бывают и полезные вещи, например боты-нотификаторы. В ICQ был в своё время популярен бот, отвечающий на ряд запросов - можно было спросить прогноз погоды или рассказать анекдот;
  
• боты в MMO-играх: сбор ресурсов, ожидание в очередях и т.п. Также спам в чаты (продажа ресурсов/золота, как легальная так и не очень, рекрутинг в гильдии);
  

В целом, понимайте схемы как пространства имен. Схемы помогают логически организовать структуру БД. Различные приложения или компоненты приложений внутри себя имеют более высокую связность, чем между собой, тоже самое и с данными в БД - часто таблицы сами по себе организуются в логические группы, причем внутри группы связей довольно много (внешние ключи, какие-то общие хранимые процедуры и т.д.), а между этими группами - мало или нет вовсе.

Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

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

А что будет если несколько юзеров будут на одну public-схему коннектиться?

Помимо того, что схема - это пространство имен, в большинстве СУБД это еще и пространство безопасности. Даже в рамках одного многокомпонентного приложения имеет смысл ставить границы безопасности для ограничения возможных потерь и разрушений в случае компрометации одного из компонент.

Вот допустим, у вас есть отдельная схема для таблицы авторизации и аутентификации и отдельная - для корпоративного форума. Сервис авторизации у вас выполнен отдельно от форума (например, авторизация выдаёт токены пользователю, с которыми он потом может зайти на форум). С точки зрения безопаности было бы логичным выдать сервису авторизации и форума различных пользователей в базе - тогда, при взломе форума невозможно будет получить доступ к паролям в базе или изменить права на портале, подправив данные в таблице ролей. Конечно, многие СУБД разрешают ставить права на отдельные таблицы, однако схема в данном случае играет роль контейнера и позволяет проставить единые правила для всех таблиц внутри неё.

то есть при работе в постгре предпочтительнее вместо отдельных баз делать разные схемы в одной

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

Вот вам еще хороший пример. У вас есть приложение для ведения бухгалтерии и складского учёта на фирме. При этом сложилось так, что вам нужно хранить на одном сервере данные нескольких разных фирм (например, вы предоставляете готовый сервис под ключ нескольким клиентам). В этой ситуации более чем логично хранить данные разных клиентов в разных БД, а данные бухгалтерского и складского учета - в различных схемах в рамках одной БД конкретного клиента.

Библиотеку для абстрагирования работы с разными СУБД могу посоветовать такую: https://github.com/SOCI/soci , только это не ORM, а именно абстракция от конкретной СУБД и конкретной клиентской библиотеки. Вообще под плюсами ORM не особо живут и плодятся ввиду принципиального отсутствия рефлексии в языке. Какие-то были на базе Qt (MOC как раз и обеспечивает для них наличие мета-объектов), но они слабо развиваются.

Советую еще раз поразмыслить над необходимостью именно генерировать SQL-запросы - возможно вам стоит писать их самому (тем более раз у вас действия простые), а вот абстракция от СУБД как раз бы пригодилась вам.
Я конечно не знаю, что у вас за проект, но раз вы используете плюсы, то у вас либо какой-то сервис с низким содержанием бизнес-логики (например, принимающий данные от устройств и пишущий базу), либо иное обслуживающее ПО, в которых обычно не очень много SQL-запросов.

Добавлю пару примеров к сказанному MiiNiPaa:
Вот такой код:

auto GetLambda() {
    return []( const int &x ) { return x*x ; } ;
}

это синтаксический сахар для такого (все это можно было писать еще и до появления лямбд):

struct Lambda {
	int operator()(const int &x) { return x * x; }
};
Lambda GetLambda() {
	return Lambda();
}

Отличие в том, что явно класс не создается, но принцип тот же. Возможно, на этом примере вам непонятно, зачем вся эта заморочка с классом. Поэтому рассмотрим другой пример. Этот код

auto GetLambda(int y) {
	return [y](const int &x) { return x*y; };
}

можно переписать так:

struct Lambda {
	int y;
	Lambda(int y) : y(y) { }
	int operator()(const int &x) { return x*y; }
};
Lambda GetLambda(int y) {
	return Lambda(y);
}

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

https://github.com/raml-org/raml-spec/blob/raml-10...

Map Types
Maps (aka Dictionaries) can be declared by creating an object type and declaring a special property called "[]":

#%RAML 1.0
title: My API With Types
types:
  MapOfNumbers:
    type: object
    properties:
      []:
        type: number

В вашем случае думаю будет достаточно заменить type: number на type: string. Посмотрите еще additionalProperties, из той же оперы.

Если вы обязаны жить с разделением архитектурных слоёв, о котором вы упомянули и не можете ничего поменять: первый вариант "тип" - "инициализатор" вижу наиболее удобным. Все равно придется добавлять маппинг при добавлении нового типа объекта.
Вообще можно конечно продолжить извращение и воспользоваться рефлексией и сделать автомаппинг классов "модели" на наследников GameObject. Например, искать все классы "модели" в определенном неймспейсе и искать такие же в другом (которые, в свою очередь, будут наследниками от GameObject).

Вообще, вы в каком-то смысле идете вразрез с архитектурой самого движка, т.к. GameObject-ы - это не только "представление", а и модель тоже. Я понимаю, что вы наверное не хотите создавать тяжелые GameObject-ы, когда они вроде как не нужны еще (т.е. не в области видимости), но возможно, если не добавлять их в сцену, они не будут нагружать движок.
В общем, у меня есть сомнения в том, что такое разделение на модель и представление при использовании Unity - хорошая практика.

Вам необходимо научиться применять геометрические преобразования к входным геометриям (вершинам ваших мешей).
В любом случае это происходит путем вычисления и использования матриц поворота. Для получения математической основы гуглите операции с матрицами и векторами (линейная алгебра, выч. геометрия).
Как это делать конкретно в OpenGL - зависит от используемой вами версии API. Если это "старый" OpenGL, например версии 2.0, то там glRotate и прочие функции оперирования матрицами мировых и видовых преобразований. Если это OpenGL 3.0 и позже - то читайте про вершинные шейдеры и преобразования вершин в шейдерах.

И в дополнение ещё вопросик: в каком типе поля лучше хранить md5-хэш (с индексом по нему)?

BINARY(16). VAR не нужен, т.к. длина хэша постоянна, строка фиксированного размера будет работать намного веселее. В CHAR не вижу смысла - хэш по сути есть последовательность байт, ну или если хотите - большое число. Хранить его hex-строкой считаю странной практикой. В базе посмотреть удобно, больше преимуществ не вижу.

P.S. Не забывайте, что голый MD5 давно не считается безопасным.

то в чем профит использования rvalue ссылок в семантике перемещения

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

Использование std::move - это возможность назвать некоторый постоянный с точки зрения языка объект (например, обыкновенную локальную переменную) временным, когда есть уверенность, что его содержимое не нужно далее по коду. Для него все также будет вызван деструктор (т.е. объект, попавший под move-семантику НЕ считается разрушенным после этого), но после процедуры перемещения считается, что объект находится в некотором неопределенном ("пустом"), но валидном состоянии.

Откройте для себя NuGet, NPM и Bower.

Подготовленные выражения защищают от SQL-инъекций тем, что отделяют синтаксис запроса от значений параметров запроса. Суть любой SQL-инъекции - изменить синтаксис (текст, если угодно) запроса тем или иным образом. Если вы передаете текст запроса и параметры отдельно, не будет никакой возможности повлиять на синтаксис запроса из параметра запроса.

В случае поддержки со стороны СУБД, подтоговленные выражения PHP должны использовать возможности СУБД и передавать ей сначала текст запроса для компиляции, а уже потом, отдельно - параметры запроса.

Теоретически, проблемы могут быть только в случае, если prepared statements не поддерживаются самой СУБД и эмулируются PDO (т.е. на стороне скрипта, а не БД). Тогда косяки в реализации сборки конечного запроса могут сказаться на безопасности. В случае поддержки со стороны СУБД "реализовывать" просто напросто нечего - вы защищены от инъекций не за счет экранирования всего и вся, а за счет правильного подхода - никогда не смешивать сам запрос и его параметры.

Насколько мне известно, mysql уже давным-давно поддерживает prepared statements, поэтому не вижу смысла бояться их использовать. А даже если б это было не так, вероятность в том, что при ручной сборке запроса накосячите ВЫ - гораздо выше.

UPDATE: полезнейший коммент на странице php.net/manual/ru/pdo.prepare.php:

With PDO_MYSQL you need to remember about the PDO::ATTR_EMULATE_PREPARES option.

The default value is TRUE, like
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true);

This means that no prepared statement is created with $dbh->prepare() call. With exec() call PDO replaces the placeholders with values itself and sends MySQL a generic query string.

The first consequence is that the call $dbh->prepare('garbage');
reports no error. You will get an SQL error during the $dbh->exec() call.
The second one is the SQL injection risk in special cases, like using a placeholder for the table name.

The reason for emulation is a poor performance of MySQL with prepared statements. Emulation works significantly faster.

Так что да, есть доля внезапности в поведении PDO. Я думаю стоит порыть инфы о настройке PDO::ATTR_EMULATE_PREPARES. Я считаю, что включать по-дефолту именно эмуляцию - это в высшей степени недальновидное решение. Проблемы MySQL затыкаются на стороне стандартной библиотеки языка....

поля объявленные в производном классе исчезают?

Это называется object slicing. Это явление проявляется в языках, где сложные типы данных вроде классов и записей а) могут наследоваться и добавлять новые поля при наследовании; б) могут присваиваться по-значению (by value). Это и приводит к тому, что поля потомка при присвоении в переменную типа предка отсекаются. Такое присвоение само по себе некорректно, т.к. если вы работаете с объектами классов-наследников через интерфейс базового класса, это подразумевает полиморфное поведение и работу через ссылку/указатель, т.е. чтобы вместо самого объекта копировалась ссылка/указатель на него (т.е. его identity, "уникальный ключ"), а сам оставался нетронутым и лежал там же, где и лежал.

При работе через ССЫЛКУ на базовый класс (т.е. Base&) таких проблем не будет, однако ссылка сама по себе переменной не является (в отличие от указателя) - это лишь дополнительное ИМЯ для некоторой другой переменной или области памяти. Поэтому, вы не сможете сохранить ссылку в векторе - ваш код не скомпилируется. В векторе вам нужно будет хранить указатели. Например, std::vector<Base*>.

Запомните простое правило - если ваши объекты подразумевают работу через интерфейс базового класса (т.е. полимофрное поведение), то в большинстве случаев вам следует работать с ними через указатель (и, в большинстве случаев, размещать эти объекты в куче). В том числе через умные указатели (unique_ptr, shared_ptr).

В других языках (C#, D вроде тоже) существует фундаментальное разделение на типы-значения и ссылочные типы, и для всех ссылочных типов работа "через ссылку" предоставляется автоматически. В C++ такого разделения нет, и как работать с типом вы выбираете сами, при его ИСПОЛЬЗОВАНИИ (т.е. используете либо по-значению, либо через указатель).

P.S. С днем рождения!