Почему вы хотите получить два совершенно не связанных друг с другом фрагмента данных одним и тем же запросом?
Вы можете заняться акробатикой, генерируя rowid для каждого результата из обзоров и новостей, а затем объединяя результаты в rowids; или выбрав одинаковые столбцы из обоих и используя UNION, как предложил BrynJ. Но все это кажется совершенно ненужным, когда вы можете просто выполнить два запроса.
Эти вещи принадлежат друг другу?
Если бы вы писали это, используя объекты в памяти, а не в базе данных - была бы у вас какая-нибудь Коллекция, включающая обе, или две отдельные коллекции, которые содержали их отдельно?
Обновление
Я получил ответы на свои вопросы в комментариях; Теперь я понимаю, что вы пытаетесь сделать. Я видел, как это делается двумя способами: один - выбрать самые последние данные из всех источников (комментарии, обзоры, новости, загруженные фотографии и т. Д.), Отсортировать их по дате и получить X лучших из них. на клиенте. Это имеет недостаток, заключающийся в том, что количество запросов увеличивается пропорционально количеству источников данных, но имеет преимущество в том, что он очень гибкий с точки зрения уровня представления - вы можете выбирать разные столбцы из разных объектов, форматировать их по мере необходимости. желайте и делайте все, что вам нужно, на стороне клиента (в данном случае клиентом является ваше программное обеспечение, а не веб-клиент).
Другой - обеспечить согласованный набор столбцов, которые вам нужны для представления любого объекта, который может быть нулевым - обычно такого типа, как «тип, заголовок, тело, дата, img_id» или что-то в этом роде, - и использовать союз, как предложено другим плакатом. Это позволяет вам использовать один запрос, что делает ваше программное обеспечение менее сложным; у него есть недостатки, заключающиеся в том, что он дает вам меньшую гибкость, когда речь идет о других типах вещей, которые вы, возможно, захотите вставить в канал, и, возможно, перегружает базу данных (эта часть зависит от того, насколько узким местом является БД в вашем случае).