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

Давайте условимся говорить о формате sqlite, раз уже выяснили в комментариях.
Итак, качайте command-line shell отсюда: sqlite.org/download.html
Запускаете его, указав в качестве параметра имя нового файла БД, например sqlite3 demo.db (пример тут).
Дальше все инструкции на SQL поочередно вставляете и выполняете. Все будет писаться в указанный вами файл.

Если очень хочется GUI, то SQLiteStudio - то, что я обычно рекомендую. Там также нужно будет подключить новую БД, и выполнить в ней все ваши SQL конструкции.

Впрочем, Руслан Федосеев привел куда более удобный вариант, чем по одному запросу кидать))

BEGIN TRANSACTION
-- Вставляете строки порциями по 10-100К штук
COMMIT

download.geofabrik.de

Определяете регион, в котором находится ваш город, качаете файл (немаленький), затем выковыриваете геометрию домов и их адреса.

Кстати, эта фишка (маппинг человеческих адресов на фичи) называется геокодинг.

Все зависит от того, что предполагается давать пользователю в управление. Если сервис таков, что юзер никогда-никогда не должен получать доступ к базе, то тогда можно в одном наборе таблиц. Хотя разные БД будут проще в администрировании и на порядок безопаснее (вдруг где-то забудете сделать WHERE по id магазина). Если между магазами не будет общих данных, тогда преимуществ от использования одной базы ИМХО практически нет.

Например - человек купил карандаш, потом он ее обменял на цветной карандаш, потом он обменял на шариковую ручку и так далее.

Это обычно называют история действий, "история" - ключевое слово. Вот вам вариант записи таблицы истории действий:
[<субъект> | <номер последовательности> | <датавремя>] | <объект> | <действие>
То, что в кв. скобках - ключ записи.
Если скажете подробнее, что делаете - кто субъект, какие действия выполняет - предложим и более конкретную схему таблицы.

> и для каждого из них есть уникальные поля
А как этими полями будут пользоваться? Группировки/фильтры/агрегация по ним будут?
Если будут, то тогда действительно 20 таблиц (и это нормально, т.к. тогда и кода для каждого типа пользователя у вас будет достаточно). И паттерны наследования - concrete table, single table, class table.
Если не будут (т.е. эти поля будут читаться/писаться целиком) - может в JSON поле их?

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

MySQL: https://dev.mysql.com/doc/refman/5.0/en/set-transa...
А вот с Кассандрой будет сложнее: www.datastax.com/dev/blog/row-level-isolation

IP-адрес это число. Для IPv4 - это 4 байта. Для IPv6 - это 16 байт.
Если нужен только v4 - тогда можно взять INT. Если нужно и то и другое, то
а) советую хранить оба адреса независимо, на время перехода они обычно доступны одновременно (если какой-то останется неизвестным - ничего страшного, пометите как NULL)
б) хранить в виде строки смысла не вижу вообще, БД это место для хранения данных, а не для интерфейс для просмотра, и ориентироваться надо на хранение. Кто хочет красиво вывести - пусть строит нужный запрос с препобразованиями, выше уже привели отличные функции.
в) храните в binary(4) и binary(16) чтобы иметь унифицированный подход (мне так было удобнее, советую и вам)
г) только не надо varbinary - размер адреса постоянен, никакого var быть не может. Типы данных с фиксированным размером (даже binary) намного легче в хранении и обработке, чем с переменным. Не мучайте СУБД не по делу.

Ваша сочетаемость цветов - это обычный граф в чистом виде. Вершины - цвета, ребро - факт сочетаемости двух цветов. Как хранить этот граф - дело десятое. Как вносить его в систему - тоже отдельный вопрос, хотя забивать конечно это все придется вручную, т.к. сочетаемость - это на 80-90% субъективное восприятие.

Для подбора N предметов разного цвета (ну или просто N различных цветов для M >= N различных предметов) найдите подграф с нужным количеством вершин, где все вершины связаны друг другом, включающий некоторые заданные вершины. Например, подграф из 3-х вершин, содержащий вершину "зеленый", при этом каждая вершина подграфа связана с другой вершиной ребром (т.е. длина пути всегда равна 1). Это значит, что в комплекте у вас будут только совместимые друг с другом цвета, один из которых - зеленый.
Можно увеличить длину пути до 2-х, тогда, если белый будет совместим с черным, черный - с зеленым, но белый НЕ совместим с зеленым, то тем не менее такой набор цветов будет приемлемым.

https://www.percona.com/blog/2013/10/21/using-the-...

select zip from postalcodes where st_contains(geom, point(-122.409153, 37.77765));

пишут, что для работы с ограничивающим прямоугольником достаточно contains вместо st_contains.
Не забудьте почитать про поддерживаемые индексы и построить их (без дерева будет тяжко селектить).

Есть вариант использовать key-value хранилище для key-value данных, раз у вас именно такие. Зачем вам пытаться искать схему данных, если этой схемы не предвидится? Возьмите Монгу, раз поля о разных клиентах разные.

Расскажите пожалуйста, какую еще вам нужно информацию хранить о документах. То, что вы сейчас перечислили, сохранит любая файловая система, ну или на крайняк, система контроля версий. И это решение будет лучше, чем с базой, т.к. не будет избыточности (значит, не будет рассинхронизации). Может вам поиск нужен по атрибутам или по тексту? Тогда это другая история.

Четыре раза перечитал - так и не понял, зачем вам time при айдейте поля с ID процесса на ноль. Если вы сначала делаете так:
UPDATE `test` SET `lock` = 1 WHERE `lock` = 123456
то почему потом не сделать с точностью до наборот?
UPDATE `test` SET `lock` = 0 WHERE `lock` = 1

Если вы скажете, что несколько процессов могут выполнять задание, и нельзя просто так проставить нули всем заданиям, у кого 1, то я вам скажу, что вам нужна нормальная структура таблицы, и стоит разделить "lock" и "process_id". Хотя конечно непонятно, зачем вам такой переход: 0 -> process_id -> 1 -> 0, сделайте 0 -> process_id -> 0, и у вас будут нормальные запросы:

UPDATE `test` SET `process_id` = 123456 WHERE `process_id` = 0 ORDER BY `time` LIMIT 1000
UPDATE `test` SET `process_id` = 0 WHERE `process_id` = 123456

Советую ERWin (коммерческий) и Oracle Data Modeler (бесплатный), а из книг возьмите Дейта для начала.