Тем, что не имеет никакого отношения к MS Sql Server, полагаю.
eai
Нужно определиться, что Вы хотите. С какой(какими) СУБД работать. Вообще, используйте паттерн Adapter и абстрагируйтесь от реализации запросов в ORM. В большинстве случаев это можно сделать. Либо же используйте в Вашем SQL только то, что поддерживается всеми СУБД, которые предполагается использовать - это уже сложнее, поскольку стандарту в полной мере не следует ни одна.
Мелкий
У строк никогда не было и не планируется "текстовых" индексов. Строка - не массив, её индексы могут быть только целыми неотрицательными значениями. Всё, что не-целое, будет приведено к целочисленному типу. Например, индекс "3.5" будет интерпретирован как "3". А упомянутое "blabla" - как 0. Разумеется, при этом будет сгенерировано предупреждение.
Нет. Имеется ввиду моя невнимательность (постфиксы у таблиц разные). Однако, подозреваю, выбор такой архитектуры - не лучший выбор (поскольку что, если типов будет, например, 100). Поэтому я рекомендовал бы иметь одну таблицу, в которую следовало бы добавить колонку для выбираемого типа.
Зачем CASE? Можно просто подставить значение в подзапрос. Ещё правильнее - сделать соответствующий JOIN, иметь одну таблицу и добавить в неё колонку для выбираемого типа.
algebra
Потому что нужно применять другую организацию авторизации - и не смешивать проверку того, корректен ли ввод пользовательских данных с проверкой, авторизован ли пользователь. Примеров верной организации в Сети очень много - поэтому не думаю, что есть смысл повторяться и приводить какой-либо код.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 8901
