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 символа. Вы на чем пишите вообще?
Что ж в ней разношерстного?) Время и место занятий, предмет - для расписания. Для мероприятий - время и место проведения, организатор, описание в свободном виде. Данные реляционные дальше некуда) Связи простые, джоины хорошо выполнят свою задачу.
Там есть ссылочка "Просмотр сведений", и в открывшемся окне есть InnerException. Вероятно, там будет более конкретная информация.
И сразу спрошу - откуда взят логин? Это Windows-логин или логин в SQL Server? Если Windows-типа, то винда в домене или вы дома сидите?
Если так, то если честно, не вижу смысла в таком усложнении. Бэкенд на то вам и нужен, чтобы реализовывать бизнес-логику и работать с базой. В принципе, бывают случаи когда это может быть полезно, но во-первых тогда между MVC-сайтом и промежуточным API нет особо смысла использовать HTTP (можно поискать более подходящий и легкий протокол), а во-вторых вам скорее всего это не нужно.
Если у вас часть контроллеров возвращают вьюшки, а часть - только JSON (т.е. работают как API-контроллеры), это совершенно нормально. Более того, если вы напишите сайт как SPA, то только API-контроллеры и останутся у вас (можно считать это вырожденным случаем).
Такую схему как вы предложили используют, когда один сервис обращается к другому, и между ними нет доверительных отношений - например, какой-нибудь новостной агрегатор обращается к первоисточнику новостей. Ну или например централизованный сервис бронирования отелей обращается к API конкретной сети отелей при бронировании номера. Тогда подобная схема складывается естественным образом, т.к. оба сервиса существуют самостоятельно и в общем случае не собираются давать друг другу непосредственный доступ к БД. А вы сами пишите свое приложение.
P.S. Если вы хотите сделать обыкновенную Class library DLL-ку, и убрать туда сущности и бизнес-логику, ORM-маппинги - это другое дело, это можно.