|
Database Inside: условие WHERE при извлечении данных
|
|||
---|---|---|---|
#18+
Очень полезная штука. Пригодилась вынуть нужное из обрезанной на диске базы (чтение за концом файла). Вот если бы ещё задать условие WHERE при извлечении данных из таблиц в набор файлов со скриптами - было бы просто замечательно! Правда, сейчас при массовой пометке таблиц к извлечению общим списком так влёт это может и не получиться (WHERE надо же указывать применительно к каждой таблице или не указывать вовсе). Пример: вынимал данные из битой базы. База, как оказалось, дохла долго и админ клиента не следил за логами. Удачный бэкап оказался только недельной давности. Но данных в базе за 7 лет. Надо было извлечь текучку за 7 дней из нескольких таблиц-миллионников и перенести скриптом в базу, вынутую из недельной давности бэкапа. Результирующие скрипты в 1 с лишним Гб на каждую таблицу порадовали. Конечно, разбиение файлов на несколько меньшего размера спасло меня и я оперировал реально в текстовом редакторе уже только с сотней мегабайт текста. Но ковыряясь с этим, подумалось, что WHERE был бы очень неплох, т.к. условие это можно было бы применять между чтением записи и выводом её данных в файл с INSERT-скриптом, что позволило бы сильно сократить результирующие файлы с INSERT-операторами. -- "И это пройдет" ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 09:21 |
|
Database Inside: условие WHERE при извлечении данных
|
|||
---|---|---|---|
#18+
Уууууу... Мысль-то такая у меня была, но я ее прогнал с матюками. Полноценный WHERE там ваять нет никакого желания по понятным, наверное, причинам. Теоретически можно прикрутить механизм фильтрации как для сеток с данными, с тем же интерфейсом ввода условий. Скорее всего, этого будет вполне достаточно в абсолютном большинстве случаев. Еще номер транзакции туда можно включить. Но когда до всего этого руки дойдут - фиг его знает. А чего в файлы лил, а не в базу? Дольше, конечно, зато потом как угодно нужные данные селектить можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 11:48 |
|
Database Inside: условие WHERE при извлечении данных
|
|||
---|---|---|---|
#18+
IBExpertУууууу... Мысль-то такая у меня была, но я ее прогнал с матюками. Полноценный WHERE там ваять нет никакого желания по понятным, наверное, причинам. Теоретически можно прикрутить механизм фильтрации как для сеток с данными, с тем же интерфейсом ввода условий. Скорее всего, этого будет вполне достаточно в абсолютном большинстве случаев. Еще номер транзакции туда можно включить. Но когда до всего этого руки дойдут - фиг его знает. А чего в файлы лил, а не в базу? Дольше, конечно, зато потом как угодно нужные данные селектить можно. Всё понятно. И причины, и прочее. Просто мысль на поверхности была, как говорится. В базу мне, показалось, геморроя больше лить. Ибо не просёк ещё "всю полезность всех возможностей" :) Хотя, это ведь получилась бы "недобаза" из только нужных мне таблиц безо всяких индексов и прочего?.. Пуркуа бы да ни па?! Надо попробовать с остатками огрызков :) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 13:07 |
|
Database Inside: условие WHERE при извлечении данных
|
|||
---|---|---|---|
#18+
IBExpertТеоретически можно прикрутить механизм фильтрации как для сеток с данными, с тем же интерфейсом ввода условий. Скорее всего, этого будет вполне достаточно в абсолютном большинстве случаев. Еще номер транзакции туда можно включить. Но когда до всего этого руки дойдут - фиг его знает. Считаю, что уж точно не будет лишним перечисленное. Собственно, под WHERE я и понимал в данном случае именно что-то подобное - просто фильтр по содержимому поля без каких-то полноценных выражений, вычислений, сравнений полей и т.п. Меня бы это устроило в моей ситуации на все 100%. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2016, 13:10 |
|
|
start [/forum/topic.php?fid=42&fpage=24&tid=1599326]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 143ms |
0 / 0 |