Vitsliputsli, Ну... да. Тут "каков вопрос, таков и ответ". Конечно, CHECK (id_1 < id_2) проще. С другой стороны, и решение в ответе, и это - плевок в сторону нормализации.
...
4. Использование имени поля выходного набора в предложение WHERE;
5. Использование зарезервированного слова в качестве имени объекта без требуемого квотирования;
6. Использование неправильного типа кавычек для квотирования имён объектов.
Как правильно определять какому уровню принадлежит user
Вопрос лишён смысла. Уровень юзера можно определять только относительный - по сравнению с другим юзером, находящемся в том же дереве ссылок и являющимся его прямым родителем. И его можно лишь считать абсолютным - если он рассчитывается относительно юзера, у которого нет родителя.
В принципе ничто не мешает при создании записи вычислять и хранить уровень пользователя относительно корневого пользователя данного дерева рефералов (фактически абсолютный уровень). Тогда относительный уровень определяется как разность абсолютных, если сравниваемые записи находятся в одном ссылочном дереве, либо не определён, если записи находятся в разных деревьях.
Неясно. В таблице уже имеются строки, и в них надо выполнить заполнение с увеличением номера? или надо для следующих вставляемых записей обеспечить продолжение нумерации?
Slash, как бы каждому полю надо присваивать нужный collation. Всем огульно - никакого смысла нету, как правило у большинства не задаём, и используется collation таблицы. Но да, можно. И нет, проблем при этом быть не может - разве что если collation не соответствует требуемому. Главное - не нарваться на несовместимость collation двух операндов.
vladimir328, что именно Вы не понимаете? какой должен получиться запрос? или как его получить в коде на PHP в программе? или как его передать из программы на сервер? или что-то ещё?
Изменение данных в БД выполняется запросом UPDATE. В нём указываются только изменяющиеся поля и новые значения (а также в секции WHERE соответствующие условия отбора записей для обновления - туда тебе надо передавать ID изменяемой записи). Значения полей, не указанных в SET-секции UPDATE, не изменятся.
если имеется в виду, что надо вводимое значение заменять на NULL, если такое значение уже присутствует в столбце - то это работа для триггера... только как ты потом собираешься различать, какое значение было заменено на NULL?
Если ORDER NO есть имя создаваемого ограничения - оно должно быть слитным литералом. В MS Access это достигается обрамлением в квадратные скобки.
Если же это что-то иное - то не по месту расположенное служебное и резервированное слово ORDER есть заведомая синтаксическая ошибка.
Да, пробел в обрамлённом двойной кавычкой имени поля тоже скорее всего как минимум опечатка. Да и вообще использование двойных кавычек для квотирования имён объектов - странно.
RedFirefly, RSTP наплевать на виланы, он просто строит дерево соединений коммутаторов и обеспечивает отсутствие петель. Передача трафика в виланах никак не зависит от работы RSTP, просто на основании дерева связей коммутатор будет принимать решение, через какой порт какому коммутатору направить пакет.
Для простоты можешь думать (хоть это и не так), что MSTP - это просто куча независимых RSTP, каждый из которых самостоятельно обслуживает некий набор виланов, тогда как RSTP обслуживает все виланы сразу.