|
| |
|
|
| |
для: Trianon
(31.03.2010 в 18:08)
| | | Ясно, Спасибо. | |
| |
|
|
| |
|
|
| |
для: brokonyer
(31.03.2010 в 11:22)
| | | Видимо тогда придется ввести столбик name2 или как-то так. | |
| |
|
|
| |
|
|
| |
для: Trianon
(31.03.2010 в 09:00)
| | | Да. но тут не только ID играет роли но и NAME тоже, если даже ID совпадает NAME может и не совпадать, в этот момент нужно сохранить обе версии параметра NAME.
И задача в том чтобы вывести все не соответствующие строки. Легче подойти к этому методом исключением. Но не теряя нужную задачу. | |
| |
|
|
| |
|
|
| |
для: brokonyer
(31.03.2010 в 07:03)
| | | > Если это обозначает принадлежность к первому и к второму таблицу а both есть совпадающие строки,
да. именно так.
>тогда мне еще придется добавить еще один этап где их надо сравнить и по результатам присвоить both.
Собственно, это делается на этапе добавления строк. С помощью конструкции ON DUPLICATE KEY UPDATE
Зато операция разовая, и куда менее затратная, чем предыдущая, т.к. сравнение происходит по уникальному индексу. | |
| |
|
|
| |
|
|
| |
для: Trianon
(31.03.2010 в 01:17)
| | | Я не очень то понял в чем фишка и для чего first, second, both? Если это обозначает принадлежность к первому и к второму таблицу а both есть совпадающие строки, тогда мне еще придется добавить еще один этап где их надо сравнить и по результатам присвоить both. | |
| |
|
|
| |
|
|
| |
для: brokonyer
(31.03.2010 в 01:06)
| | | Если этот признак хранить в виде (1/2/3 === first/second|/both) , иными словами, если в такой таблице строка, принадлежащая обеим наборам, всё же будет проявлена один раз (с признаком both), а не два (c признаками first и second) - эффект будет. | |
| |
|
|
| |
|
|
| |
для: Trianon
(30.03.2010 в 13:03)
| | | это плохо..
я в первые столкнулся с такой ситуацией, есть ли альтернативная решение этой задачи?
у меня там цифры в INT, а текст VARCHAR
Если поместить эти 10000 строк в одну Таблицу (итого 20000 строк в таблице будет), только добавив параметр с помощью которого можно разделить их по запросам, эффект от этого будет? | |
| |
|
|
| |
|
|
| |
для: brokonyer
(30.03.2010 в 06:12)
| | | Это если бы в одной таблице.
А две таблицы без прямой связи по индексу создают декартово произведение - более сотни миллионов строк, которые нужно пропустить через фильтр.
Кстати, как у Вас десять тысяч строк вмещается в TINYINT? | |
| |
|
|
| |
|
|
| |
для: devart
(09.03.2010 в 12:21)
| | | Думаю для веб приложении это не сгодится, пригоден только для самого разработчика... | |
| |
|
|
| |
|
|
| |
для: exp
(09.03.2010 в 00:53)
| | | При больших количеств строк в обоих баз БД не выполняет запрос и толи зависает толи обрывается связь, толи он сервере его выполняет очень долго и просто сбрасывает web подключение... Как можно с этим боротся? Число строк в обоих Таблицах превышает 10000. Но думаю такая количество не должно быть помехой для Mysql | |
| |
|
|
|
