Владимир Семенякин
> Дело в том, что, как я понял, git не поддерживает возможность привязки отдельных папок, даже через механизм подмодулей (только что проверял - не вышло через подмодули).
Гит отдельные папки действительно не поддерживает, это несколько противоречит его архитектуре (а именно, тому, коммит - это всегда новая версия всего репозитория целиком). Но тут речь совсем не про гит. Подключение библиотеки сабмодулями - это скорее временное решение, или решение для очень маленьких header-only библиотек. Речь все-таки о том, чтобы научиться передавать компилятору ключи с путями к инклудам и lib-ам. Тогда библиотека может спокойно собираться отдельно и лежать в отдельной, а зависимые от нее проекты - отдельно. Как это делать лучше всего - зависит от сборочной системы. Для CMake я приводил пример.
> А зачем? Тесты - штука побочная, почти служебная в рамках библиотеки, можно сказать. Чего замусоривать пользовательский билд служебные подобными штуками?
М, я имел в виду что тесты в идеале должны иметь в качестве зависимости тестируемую библиотеку. И для сборки тестов уж точно ничего не надо копировать - достаточно натравить компилятор на папки include и lib в корне репозитория. Т.к. пути в данном случае будут относительными, это еще проще, чем при подключении библиотеки в другой проект.
> Да, я уже собирал assimp с cmake (первое моё знакомство с cmake) - чуть с ума не свихнулся пока сделал, день потратил на сборку.
Ну это нормально, тут нужно просто разобраться и все. Я потратил несколько дней, чтобы нормальный CMakeLists.txt составить для библиотечки, но оно того стоило. В общем-то сейчас это лучший вариант для кроссплатформенных библиотек. Autotools точно не легче в понимании). К сожалению, с плюсами используются довольно много систем сборки - и классический make, и CMake, и SConstruct, и GYP, и много чего еще, это сейчас проблема в экосистеме C++. И все-таки советую CMake, т.к. в современных проектах она явно популярнее остальных.
Даже если вы считаете, что вашу библиотеку будет удобно подключить как сабмодуль, вам все равно нужно точно так же уметь сообщить компилятору, где лежат инклуды. Копировать инклуды либы прямо в папку с инклудами проекта - довольно плохая идея.
Много - это сколько? У меня букмарков более 12 тысяч, проблем с производительностью не наблюдается (кстати, firefox и так все в sqlite-базе хранит). У вас больше?
wadeg Ну за Оракл говорить не буду, но вот в Постгресе есть такая процедура, как VACUUM, и время от времени ее проводить бывает полезным (если было много удалений и есть много "мертвых" кортежей).
Это называется like или поиск подстроки, и это все к полнотекстовому поиску никакого отношения не имеет.
Под полнотекстовым поиском я понимаю индекс для поиска в середине, такой, по которому можно искать LIKE '%str', где обычное B-дерево не поможет. Я не про морфологию, операторы и/или и прочие высокоуровневые навороты.
wadeg Воистину перепутал с BLOB, посыпаю голову пеплом:). Просто у меня много дискуссий на счет них было последнее время (BLOB vs файловая система)..
Полнотекстовой поиск я предложил, т.к. стандартная задача, которую хотят в таких ситуациях - искать в том числе в середине строки: врядли все будут искать номер автомобиля только с начала. Обычно это поле а-ля "быстрый поиск", куда вбивается все, что хочется.
Запросы на вставку/обновление с полем переменной длины будут дороже однозначно, т.к. записи также будут переменной длины и сложнее поддерживать карту свободного места. Либо придется делать компрессию время от времени (тут нужно про конкретную СУБД говорить). Хотя, если записи не удаляются и не обновляются, тогда без разницы)
А почему код должен потерять форматирование? Почему content-type json-овский, почему не text/plain? Нельзя ли послать код в отдельном запросе с подходящим content-type?
Tsiren Naimanov я понял вас так: клиент --http--> asp.net mvc --http--> asp.net web api --> БД.
Если так, то если честно, не вижу смысла в таком усложнении. Бэкенд на то вам и нужен, чтобы реализовывать бизнес-логику и работать с базой. В принципе, бывают случаи когда это может быть полезно, но во-первых тогда между MVC-сайтом и промежуточным API нет особо смысла использовать HTTP (можно поискать более подходящий и легкий протокол), а во-вторых вам скорее всего это не нужно.
Если у вас часть контроллеров возвращают вьюшки, а часть - только JSON (т.е. работают как API-контроллеры), это совершенно нормально. Более того, если вы напишите сайт как SPA, то только API-контроллеры и останутся у вас (можно считать это вырожденным случаем).
Такую схему как вы предложили используют, когда один сервис обращается к другому, и между ними нет доверительных отношений - например, какой-нибудь новостной агрегатор обращается к первоисточнику новостей. Ну или например централизованный сервис бронирования отелей обращается к API конкретной сети отелей при бронировании номера. Тогда подобная схема складывается естественным образом, т.к. оба сервиса существуют самостоятельно и в общем случае не собираются давать друг другу непосредственный доступ к БД. А вы сами пишите свое приложение.
P.S. Если вы хотите сделать обыкновенную Class library DLL-ку, и убрать туда сущности и бизнес-логику, ORM-маппинги - это другое дело, это можно.
Вы какой-либо http-клиент уже используете, или вам предложить? Если уже используете, то какой (полное название класса, название NuGet-пакета, если класс не из Фреймворка), что конкретно пытались сделать и что не получилось.
Александр Дегтярев и еще третий субъективный критерий: если вы пользовались до этого SQL-базами, обязательно внимательно читайте документацию и возможности той NoSQL-базы, которую вы выбрали. Многие из них внезапно могут не иметь тех свойств и гарантий, которые кажутся обязательными и само-собой разумеющимися в мире SQL. Это прямое следствие других подходов к архитектуре и других требований к СУБД. Есть проекты, где "быстро" важнее чем "точно" (см. eventual consistency).
Александр Дегтярев в целом говорить не совсем правильно, т.к. моделей данных и моделей хранения действительно разных очень много. Есть близкие к SQL, "почти-SQL", вроде Кассандры, а есть максимально простые хранилища вроде Redis. NoSQL базы обычно выигрывает по мастабируемости (т.к. СУБД проще и не такая гибкая как SQL-СУБД) - репликация настраивается проще и почти всегда из коробки, и простотой использования в простых сценариях, но проигрывают в гибкости (например, в документно-ориентированных базах обычно нет понятия, аналогичного JOIN в SQL) и иногда в надежности и атомарности/изоляции транзакций. Например, Монга гарантирует атомарность транзакции только в рамках документа. Это значит, что если вы просто не можете гарантированно записать два и более документов так, чтобы параллельные транзакции увидели сразу конечный результат. Это, в свою очередь, делает эту СУБД непригодной для финансовых транзакций.
Еще есть два фактора, которые зависят не сколько от самих NoSQL моделей данных, сколько от текущей ситуации: 1) многим SQL-базам уже не один десяток лет, и они набили много шишек, и вылечили "детские" болезни, с которыми можно столкнуться в более молодых СУБД; 2) NoSQL-решения, позволяющие работать с данными в отсутствие схемы иногда играют злую шутку с разработчиком, и отсутствие той дисциплины, которая нужна при проектировании SQL-базы приводит к превращению базы в кучу неуправляемого хлама.
В целом, главный критерий, который защитит вас от многих бед - выбирать базу либо исходя из жестких требований к производительности/масштабируемости, если таковые есть, либо исходя из модели данных вашего приложения. Есть данные, которые естественно укладываются в реляционную базу, есть данные, которые просятся в документную. Любимый мой пример: информация о товаре может быть разрознена и отличаться от товара к товару, поэтому обычно лучше её хранить в документной базе с необходимыми индексами. А вот информация о покупках обычно однотипная, т.к. указывается артикул или иной код товара, код клиента, количество. Или учет этих товаров на складе. Надежность и изоляция транзакций в этом случае будет очень важна, и мой выбор - реляционная СУБД.
Александр Дегтярев какие выборки нужны? Нужны ли выборки внутри документа по разным критериям или может key-value достаточно и документно-ориентированная не нужна?
Дмитрий php.net/manual/ru/function.md5.php
Вам сейчас md5 возвращает hex-строку. Передайте вторым ($raw_output) параметром true, и будет вам двоичная строка "как есть". В базе ничего увеличивать не надо, поймите разницу между записью байт числа hex-цифрами и как есть.
nirvimel так че, отличная вещь) Именно в TD на первом курсе я с немалой долей удивления узнал, что такое little-endian)). Час не мог понять, кто ж байты-то переворачивает). Препод почему-то гораздо позже об этом рассказал...
Дмитрий потому что MD5 это хэш постоянной длины в 128 бит (https://ru.wikipedia.org/wiki/MD5), т.е. 16 байт. Хэш-строка в 32 байта - это hex-закодированные байты хэша. Т.к. каждый байт кодируется двумя hex-цифрами, то и длина hex-строки в два раза больше.
Ведь если хэш-строку в 32 символа, записывать в поле BINARY то она занимает там 64 символа.
Вот тут не совсем понял, точнее совсем не понял, почему пусть даже hex-строка должна занять 64 символа. Вы на чем пишите вообще?
