Короче читаю логи из юникс сервера, парсю их и записываю в Vector, выглядит этот вектор так:
где слева стоят мак адреса, а справа айпишники
Как видно из выше написанного, есть одинаковые маки с разными айпи (в данном случае реч идет о серваке,который имеет одну сетевую,на которой прописано 2 айпи).
Есть таблица базы данных:
Задача сравнить то что пришло,с тем, что находится в базе данных и сообщить потом по почте админу,что произошла подмена айпи например.
Короче как я делаю:
беру строчку из пришедшего на сравнение вектора, выбираю там айпи и мак, ищу есть ли в базе уже такой айпи,если есть,то проверяю соответствует ли данному айпи в базе мак который пришел из файла с этим айпи, если и маки совпадают,значит ничего не шлем админу,т.е. подмен никаких не было, если маки не совпадают,то делаем обновление мак адреса в базе ,и шлем сообщение админу,что у юзера поменялся мак адрес.Теперь,если пришедший айпи не совпал с тем,который есть в базе, но совпал мак,тогда мне нужно сделать обновление айпи адреса которому соответствует мак,вот тут весь геморой и получается, геморой вот в чем:
строка из файла zzz 3333 ---> в базе находим получается две строчки,которым соответстует мак zzz, т.е.: и
на такую ситуацию получается 2 запроса, эти 2 запроса обновляют две строки и , т.е. получается в результате 2 одинаковых записей в базе данных.Короче надеюсь меня поняли,как мне разрулить такую ситуацию.
А бывает еще и такая ситуация:
Опять же вектор:
и таблица:
Берем строчку: находим в базе запись с маком zzz , меняем у неё айпи адрес с sss на 333, потом берем следующую строчку и т.д до тех пор пока не доходим еще до одной записи из файла с маком zzz,т.е. , снова находим запись в базе данных с маком zzz и меняем, и тут гемор снова в том, что второе обновление затирает первое,т.е. нет никакого смысла от того,что было произведен апдейт на первом шаге.Короче помогите,не знаю что его делать.

LINUXERне очень понял а чего бы хотелось-то?
Может ложить в HashMap?
геморой вот в чем:
строка из файла: строка в БД: обновляю запись в базе данных:
1) update ... set ip=3333 where мак=zzz and ip=ssss
Дальше беру следующую строчку из файла,например она равна:
делаю запрос:
2) update ... set ip=pppp where мак=zzz and ip=ssss
в результате один завпрос 2) перекрывает запрос 1), как избавится от этого
Говоришь ложить в HashMap,но там могут быть одинаковые маки, а это значит,что как ключ он не годится,если в качестве ключа брать ip,тогда тоже есть гемор,но о нем позже скажу если ничего не будет предложено по поводу первой идеи

nexМне кажется, что вам нужно добавить колонку в таблицу, которая вместе с MAC адресом будет являться ключиком таблицы... Например название интерфейса. Тогда update будет таким:

update ... set ip=3333 where мак=zzz and ip=ssss and interface='eth0'

--
nexus
в том то весь и геморой,что название интерфейса тоже одинаковое

Мужики!!!!
Эта проблема решаема вообще или нет,подскажите кто что может,я уже сплю и мне маки и айпишники снятся

Michael PonomarevМожет я что и не понимаю, но вот пришло из логов

а в базе есть
Вопрос какая из записей в базе ДОЛЖНА меняться?
в том то и дело,что в таком случае меняются 2 записи в базе у которых мак равен zzz т.е. будет следующее в базе:
это первая проблема,т.к. получаются одинаковые айпишники
вторая проблема:
когда я беру например из лога строчку N, которая равняется:
он находит 2 строки с одинаковыми маками и ставит айпи равным 111, в результате получается карусель.

Michael Ponomarevя вот что пытаюсь сказать
упростим случай: пусть в логах есть только 1 строка с мак адресом ZZZ
а в базе данных 2 строки смак адресом ZZZ
т.е. есть ли правило какую из строк таблицы надо поменять? первую, вторую или обе
в данном случае будет менятся только одна строка, zzz 111, втрую трогать не нужно т.к. есть совпадение по маку и айпи.

Еще раз поясню:

первый вариант самый простой:
берем первую строку из файла:
zzz 3333
в базе данных есть ОДНА строчка с таким маком
zzz 222
айпишники не совпали--->обновляем айпишник на 3333
берем вторую строчку из файла, и вот самое интересное,пришла такая вот строка:
zzz 222
в базе такого айпи адреса уже нету, потому что он обновился в первом случае на айпи 3333,
а раз нету,он снова ему делает апдейт и устанавливает айпишник 222,вот такая вот канитель
второй вариант: когда в базе несколько строк с одинаковым маком, тут вообще жопа наступает

Michael PonomarevХорошо, а если пришло zzz 111, а базе есть
zzz 222
zzz 333
что обновлять?
может все-таки дополнительная таблица истории?
ведь в лог в хронологическом порядке пишется.
в таком случае он обновит 2 строчки,и инфа будет утеряна, нужен какой-то ключик, только хз куда его прикрутить.
Скорее всего таблица нужна,но как именно в таком случае делать,голова уже не варит совсем нафиг, пойду напьюсь

G. peter6636
в таком случае он обновит 2 строчки,и инфа будет утеряна, нужен какой-то ключик, только хз куда его прикрутить.
Скорее всего таблица нужна,но как именно в таком случае делать,голова уже не варит совсем нафиг, пойду напьюсь
Вам уже сказали что при 2 записях в таблице вы не можете определить какой из адресов изменился, например

1. получен IP1
2. получен IP2
3. IP1 изменился на IP3
4. IP3 изменился на IP4
5. IP4 изменился на IP1

и т.д.

получается что IP2 не изменялся ни разу, а Вы никак не можете определить какой из начальных адресов (IP1, IP2) менялся, здесь даже история Вам мало чем поможет
нет никак

Надеюсь все-таки есть выход из этой ситуации

Придумал, осталось закодить это все