Comments 9
можешь заюзать GENERATE_SERIES и получишь тоже самое без цикла
Так давно уже (более пятнадцати лет) существуют тенераторы тестовых данных.
sql dummy data generator online free без смс
Даешь им схему, указываешь какие колонки нужны и в каком количестве, и вперед.
И в виде онлайн инструментов и консольные
sql dummy data generator command line
И десктопные с GUI, но они обычно входят в какие-то комбайны с блоксхемами и UML.
insert into Trades (ID, ..) values ( (select max(id) + 1 from Trades), ..
Ну если получить монопольный доступ к БД при генерировании данных - сойдёт. Только в команде далеко не всегда можно сказать коллегам "А ну-ка свинтили все из базы, я счас тест-данные генерять буду"..
Опять же не следует такое делать, если id - это автоинкремент или GUID.
Компактный вид
Insert хотя бы 5 записей через набор значений values (...), (...), ... (...) получился бы гораздо длинней, большинство значений бы повторялось и читалось бы это всё тяжело.
Пять тест-записей нужны крайне редко. Обычно счёт идёт как минимум на десятки тысяч. В этих условиях INSERT по одной записи в цикле - занятие для записных мазохистов.
В Постгрессе, как уже правильно сказали выше, есть generate_series(). В SQL Server такого нет - однако есть рекурсивный CTE. А INSERT .. SELECT есть везде.
Чтобы не засорять базу, хорошо бы каждым скриптом удалять записи, полученные от его предыдущего запуска.
Ага.. а после последнего теста так и оставить этот мусор в базе. Вы это серьёзно? Планировать очистку БД от тестовых данных надо одновременно с планированием создания этих данных, и скрипт очистки писать одновременно со скриптом-генератором.
А ещё - для контроля невредно создать служебную таблицу, данные в которой позволят точно выявить все записи, вставленные тестовым скриптом. Информацию из этой таблицы можно использовать как для контроля, присутствуют ли в БД тестовые данные, так и для очистки. Почти жизненно необходимо, если параллельно будут запущены два (или больше) независимых генератора.
По доступу к базе и id
Данные генерятся быстро, если их не очень много, и коллегам это вряд ли помешает. Но, вероятность есть, да. Зависит от условий разработки.
С id надо очень аккуратно и внимательно, отталкиваясь от настроек базы/таблицы, разумеется.
По количеству тестовых записей
"Обычно" у всех свои) Для функционального тестирования алгоритмов, с которыми мне приходилось сталкиваться, было достаточно нескольких десятков, реже сотен, записей в 3-5 таблицах.
Бывало, генерил и тысячами но редко. В этих случаях, обработка нагенерённого занимала заметно больше времени, чем их создание. Там, где всё начинается от десятков тысяч, вероятно, надо что-то куда более хитрое, что-то из арсенала нагрузчиков.
По удалению
Конечно, за собой надо убирать) Если проверка автоматизирована, то в конце должен выполняться скрипт с удалением, даже если сама проверка завалилась. Об этом упомянуто. Если проверка ручная, то последним шагом должно быть удаление нагенерённого, как и в любом другом случае добавления данных или изменения настроек для конкретного тест кейса.
Удаление в начале скрипта как раз на тот случай, если в прошлый раз что-то пошло не так. Главная цель - обеспечить условия выполнения insert-ов и удалить данные, которые могут повлиять на обработку нагенерённого.
Удаление в начале скрипта как раз на тот случай, если в прошлый раз что-то пошло не так.
Но тогда нельзя не учесть вариант, что при удалении на старте скрипта тоже "что-то пойдёт не так".. уж лучше руками убедиться, что всё вычищено. А то потом можно долго гадать, почему это дважды два даёт пять. Я бы в начале скрипта ограничился контролем имеющихся данных на предмет отсутствия грязи от прошлых запусков.
Ну не знаю, у кого как, лично я на этапе проектирования БД сразу стараюсь сформировать набор пограничных данных на все случаи жизни (ключевое слово тут "стараюсь"))))). Потом, когда все запроектировано, перед тестами дампую (ПО же обязательно что-то поломает) и после очередной итерации восстанавливаю из дампа.
"В три раза" видимо против постоянного ручного перенабора? Даже банальный копипаст заранее заточненных insert-ов занимает примерно то-же что с запуском скрипта. Опять же tooday органично смотрятся внутри инсертов, как и прочие "Всегда актуальные значения из связанных таблиц".
А уж если выровнять аккуратно инсерты, в файлике очень наглядно-таблично все выглядит, не в пример скрипту.
Зачем тут огород скриптов на фоне картинки из LA2 не очень понятно.
"В три раза" против "найти подходящие из имеющихся, сделать им update под конкретный кейс, проверить, сделать update под следующий и так дальше". Об этом сказано в Результатах внедрения.
Если уже есть набор готовых insert-ов под нужные случаи, то переписывать их через цикл смысла немного, конечно. Разве что, при большом количестве полей, insert-ы, скорее всего, получатся длинными и придётся горизонтальным скроллом махать, что утомляет. Или, при большом количестве записей, лучше скрипт с циклом на один монитор, чем insert-ов на несколько...
Текст с картинкой лучше, чем без неё. Приятная картинка лучше, чем любая другая. Интересный женский силуэт, даже с ушами, скрасит любое окружение. То, что это из La2, поймут лишь побывавшие там. Они вспомнят что-то приятное, улыбнутся - уже хорошо! :) Остальные такого бонуса не получат, но увидят хорошую картинку, где герои смотрят не просто куда-то в даль, а на скрипт из статьи и решат: присоединиться к ним, или скроллить дальше. Как-то так :)
Как SQL-скриптом сократить время ручного тестирования в 3 раза и облегчить жизнь коллегам