Спасибо за ответ, такой вариант тоже рассматривался, но при количестве данных (объектов) в миллионах и множестве свойств у каждого возникает проблема с ростом памяти БД, так как NULL жрут место вроде как. А так же тяжело правильно и логично обвязать БД моделями Entity Framework.
Вопрос не про конткретно с таким примером, а именно про то что бывает сущность схожая, но разная. Например аналогичный пример, таблица с документами. У документов бывают различные (плавующее кол-во, мб сколько угодно) свойства. Свойсвтва бывают трех видов: строки, числа, даты. Их хранить лучше в трех разных таблицах. Как их правильно соединить с таблицей документов, так что бы это было правильно с идеологической стороны БД. А не со стороны, как проще. Так что бы больше проверок повесить на БД.
gemolo: Как вариант, если очень хочется, можно попробовать сделать внутреннему блоку с чатом свойство position:absolute; А скролл сделать придется отдельно, ручками при помощи JS
Спасибо за ответ. Я правильно понял, что раз нельзя просто разрезать, значит файл нужно порезать с помощью какой нибудь библиотеки ( разрезать так, что с первого по последний байт - он был полностью отдельный независимый видео-файл), и отправить только кусок оригинального файла?
Вы меня не так поняли. В SQL есть способ авторизации c помощью доменного логина. Тем самым я могу определенным ролям пользователей выдать права на разные процедуры и таблицы. В таком случае идентификацию будет проводить сам SQL Server. Второй способ: я буду держать в таблице логины пользователей и их роли, запросы с веб-сервера буду выполнять под одной учеткой (например app_user), а аутентификацию буду выполнять на веб-сервере. Например если роль подтвердилась, то возвращаю данные, иначе вызываю исключение.
Всё правильно, потому что вы их использовали в теле метода, но если их не использовать, и поставить брейкпоинт внутри метода - то увидете что их не видно.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
