15432, или это уже в библиотеке ветвится. К примеру во времена 8086 - не на каждом компьютере был 8087 и math так или иначе была обязана либо быстро считать на сопроцессоре либо "в столбик"гоняя регистры
Danil Sapegin, даже в не очень оптимальном варианте отбор и отсечение join'ами не затронет такие медленные каналы как например отдачу еще не отфильтрованной выборки.
В приведенном ТС вопросе - это максимально выпячено, так как конечный ответ атомарный - да/нет и любые варианты получения нескольких выборок по 100500 строк с последующими манипуляциями над ними - захлебнуться еще на уровне их отдачи...
Ближайшая аналогия - не отдавать мобильному клиенту ужатую до 300*200 пикселей картинку, а отдать 38 мегапиксельную картинку и обрамить ее тэгами "показать 300*200" -)
В описанном ТС случае нужен единственный бинарный ответ - так нехай sql перемолотит простенький запрос и вернет тот самый битовый ответ, а не гоняет туда-обратно море шелухи.
И авторизация - тут вообще не к месту. Ибо тут всего лишь ответ да/нет на пару userId и postId
NataliaCh, ну пользователей домена или группы можно примаппить к учеткам (внутренним).
Оба варианта имеют право на жизнь, но как мне кажется не зря дефолтный вариант установки sql сервера предлагается с win авторизацией
NataliaCh, ну можно попробовать mixed авторизацию и попробовать подключиться учеткой sql сервера
Ну и четко убедиться, что php выражении $var = "server\user" одиночный обратный слэш не выполняет специальных функций экранирования спецсимволов. То бишь вывести на консоль или в файл содержимое переменных
ибо "результат 1 запроса, потом результат второго, потом результат первого и так далее." содержит в себе взаимоисключающие мысли...
результат первого запроса - это множество строк, результат второго запроса - другое множество строк -)
А если хочется сделать этакие пересекающие расчески - ну можно конечно, но для начала надо будет определиться с порядком отбора каждого из запросов, а потом поиграться с ражированием и использовать ранжирование как ордеринг результата объединения =)
NikitaKo, вполне логично. Ибо каждый проект имеет свои нагрузки и свои перспективы и темпы роста.
Да и с виртуалками есть моменты: если несколько сотен виртуалок на паре десятков серверов - это все хорошо живет, виртуалки по мере загрузки гуляют между хостами и т.п., а если же от бедности на одного боливара взваливают кучу виртуалок - то только лишние танцы и точки отказа...
Дмитрий, тут вопрос философский.
К примеру некое приложение, которое куда-то коннектится и загружает/выгружает данные. Плюс есть пяток параметров, которые модифицируют загрузку/выгрузку.
На мой взгляд - вполне уместно хранить их именно там. А следом прицеп из например "дата-время последнего действия", "статус выполнения" и еще всякие мелочи.
Далее уже - то ли хранить это в конфиге приложения, то ли используя тот же самый функционал - в отдельном файле. Этакая более развитая идея system.ini и user.ini
Denis Bednov, из описания ТС совершенно неочевидно что именно у него будет храниться. Не исключено, что это например url неких подключений.
Впрочем ConfigurationManager совершенно не исключает и работу с другим файлом
Константин Нагибович,
1. сами средства разработки и отладки - уг, так и не дотянувшееся до уровня хотя бы до уровня какого-нибудь борландовского продукта образца 198Х года
2. общая концепция "рельс", сход с которых - близок к крушению
3. якобы низкий квалификационный порог вхождения
В итоге скорость на поверку оказывается тяп-ляп - бублик + итак сойдет, а попытки согнуть рельсы мало-мальски грамотных готовых решений приводят к велосипедам-мутантам...
"в столбик"гоняя регистры