samozvanka02Требуется:
при нажатии на кнопку "Обновить" под таблицей 1 посмотреть есть ли в таблице №2, в столбце pole 2 названия, в конце которых есть значения столбцов кода языка из первой таблицы.


Ну вот, на php это делается через повторное обращение к скрипту на сервере. Кнопка либо в форме как правило для post, либо с готовой ссылкой для get. Разобрав послание скрипт может попросить БД что-то ответить на запрос.

Что касается ответов типа не мной положено - лежи оно так вовек - тогда зачем вообще задавать вопросы.

В типовых отношения столбцы оперативно не вставляют и не удаляют. Для этого существуют строки.

samozvanka02,

Потребность оперировать столбцами скорее всего показывает что логика повернута на 90 градусов.

Можно таблицу представить так

Покупатель: Иван | Петр | Павел
Продавец: Геннадий | Григорий | Константин
Товар: Бублик | Пирожок | Беляш

А можно так

Покупатель Продавец Товар
Иван Геннадий Бублик
Петр Григорий Пирожок
Павел Константин Беляш

Я так и не врубился в задачу из двух таблиц. Не берусь утверждать что моя реакция показательна, но из практики известно что если с двумя таблицами возникает проблема, значит что-то коренным образом неправильно в этих двух таблицах. Я понимаю соединить несколько отношений, взойти от дальнего потомка к предку, навешать справочников и тп - но если таблиц только две, проблемы быть не может по определению.

Посмотрите как можно повернуть таблицу с бока на ноги и должно все проясниться.

Количество столбцов каким бы оно не было всегда детерминировано. Сколько языков на планете? Неизвестно. Ученые расходятся во мнениях. Следовательно все что заранее неизвестно придется писать в строки. Вот так.

vkle,

Это называется зависимость от выбранного пути.

Опять общие базары. Ну ладно. Есть два пути - прямой и извилистый. Естественно практика предпочитает прямой, очевидный и легкий. Что на что похоже - то оно и есть. Так вот если все начинается легко и просто - жди беды. Это значит масса неучтенных факторов внезапно вылезет как шило из мешка и будет тысячи их, over9000, в общем стопицот.

Что-то типа learning curve. http://en.wikipedia.org/wiki/Learning_curve И как назло именно к тому времени когда кривая пошла вверх, когда написаны все библиотеки, все классы и функции увязаны в плотный клубок - возникает не об ходимость. Кривая стремительным домкратом падает вниз. И падает и падает и устаканится на некотором компромиссе между хотелками и возможками. После этого люди проходят мимо и говорят: да у вас сайт-то дохлый.

Ну вот, извилистый путь как ни странно для геометрии оказывается самым прямым и свободным. Если в начале все невероятно трудно, то жди подарка. Неучтенных факторов оказывается немного и те, которые не учлись поглощаются глубоко проработанной системой без икоты.

Самое смешное что этих систем проработанных - как грязи. Зачем изобретать велосипед - посмотри как сделано и сделай так же.

Ну вот было у них два языка, в каких-то файлах поди лежало все, захотелось 10. И приполз писец системе. Теперь будут подгонять столбцы под строки. Потому что так было сделано предками.

Да, теме капец

Вам надо было сразу в проектирование БД писать. При чем тут пхп

samozvanka02deblogger,

мне ведь нужно не просто сравнить 2 массива, а проверить содержатся ли в первом массиве элементы второго?


Во-первых элементы содержатся в каждом массиве свои и вы можете только найти общие свойства по которым сравнить и сказать - эти элементы похожи.

Во-вторых, блин, таблица это не массив. Чтобы проверить содержатся ли релевантные записи в двух таблицах надо сделать запрос типа select * from table1, table2 where table1.somefiled = table2.somefiled. Or LIKE or >, or < or NULL and so on.

Например таблица

Человек
------------
Код_человека
Код_цвета_человека
Имя_человека
Фамилия_человека

Цвет
------------
Код_цвета
Название_цвета

SELECT Название_цвета FROM Человек, Цвет WHERE Код_цвета_человека = Код_цвета.

И узнАем какого цвета человек. Правильно?

Посмотрите на записи в двух таблицах. Они разве _одинаковые_? Абсолютно разные.

Единственное что мы сделали - ввели ПРИЗНАК по которому можно судить об ОТНОШЕНИЯХ записей в этих двух таблицах.

Если вас послушать то любой человек у которого две руки, две ноги, голова наверху и половые органы как у вас - это вы. Так получается в программистком мире.

Идите в рубрику Проектирование БД. Я так и не понял в чем у вас проблема с этими езыгами.