В идеале, у вас должен быть класс, который обрабатывает данные и создается при его извлечении и / или использовании для каждой записи или набора записей из БД. Объект, созданный таким образом, будет затем передаваться из функции в функцию по мере необходимости.
Такое мышление обычно приводит к тому, что люди в конечном итоге используют программное обеспечение Object Relational Mapping, которое специально разработано для обработки перемещения данных в базу данных и из нее или другого постоянного (ish) хранилища. Тем не менее, понимание цели ORM требует определенных знаний об объектно-ориентированном программировании и широко используемых шаблонах парадигмы, поэтому исследование ООП может быть лучшим местом для начала поиска ответов. Поиском википедии по этим темам было бы неплохо.
Как общее правило, учитывайте, что компьютерные системы лучше (более тестируемы, исправимы, расширяемы, заменяемы), когда отдельные части инкапсулированы (изолированы) друг от друга. Таким образом, делая что-то глобальным образом (это выходит далеко за рамки простого объявления чего-то глобального), вы соединяете части системы, которые, вероятно, не должны быть связаны.
Как осуществляется эта изоляция и в какой степени вы и тип вашей системы определяются. Если вы просто пишете какой-то простой тестовый код или простой прототип, вы можете злоупотреблять глобальным пространством столько раз, сколько захотите, так как код никогда не увидит свет (ключевое слово здесь просто). Если вы создаете простой сценарий, который помогает создать пару веб-страниц, и этот сценарий никогда не превратится в нечто большее, вам все равно не нужно сильно беспокоиться о глобальном пространстве. Но как только вы выйдете за рамки тривиального, вы действительно должны начать изолировать части системы, так как это даст вам гораздо лучший код для работы в будущем (то есть, в значительной степени, как только он будет набран и скомпилирован)
Чем сложнее становится проект, тем более изолированными должны быть детали, чтобы изменение в одной области не «проникало» через всю систему. Эту рябь можно рассматривать как необходимость что-то изменить в коде в сотне мест, а не в нескольких или в результате ошибок, возникающих после того, как не все было изменено или изменено правильно (человеческая ошибка всегда побеждает здесь).