Mam takie tabele:

USERS

[SQL] pobierz, plaintext 
id | login | haslo | miasto | kraj | data_rejestracji
[SQL] pobierz, plaintext 

PHOTOS

[SQL] pobierz, plaintext 
id | user_id
[SQL] pobierz, plaintext 

Korzystam z ORM i chciałbym otrzymać coś takiego:

[SQL] pobierz, plaintext 
user_id | login | data_rejestracji | photo_id
[SQL] pobierz, plaintext 

Dodam tylko, że każdy użytkownik może mieć dowolną ilość zdjęć a ja chcę pobrać tylko 1 zdjęcie dla każdego użytkownika (sortowanie po id, pierwsze które wystąpi) Ponadto użytkownik może nie mieć żadnego zdjęcia i wtedy w wyniku w photo_id powinien być NULL

Jak takie coś uzyskać ?

Oj, to chyba nie wiesz czym jest ORM. Radzę uzupełnić wiedzę z tego zakresu, wtedy zrozumiesz swój błąd

Czytałem, że jest to mapowanie na obiekty. Ale owszem pierwszy raz pracuję z ORM. Nie mam problemów z zapisem z pojedynczej tabeli ale z dwóch juz tak.
W modelach mam ustawione:

[PHP] pobierz, plaintext 
class Model_Photo extends ORM
{	
	protected $_has_many = array('users' => array());
 
	public function action_index()
	{
 
	}
 
} 
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
class Model_User extends ORM 
{	
	protected $_belongs_to = array('photo' => array());
	};
[PHP] pobierz, plaintext 

Więc tak.

1. Po co Ci metoda action_index w modelu? Takie metody umieszcza się w kontrolerze (no chyba, że masz ku temu powody albo po prostu nazwa jest myląca).
2. Relacje zrobiłeś w drugą stronę. Powinno być: 1 użytkownik ma n zdjęć, 1 zdjęcie należy do 1 użytkownika. U Ciebie natomiast: 1 zdjęcie ma n użytkowników, 1 użytkownik należy do 1 zdjęcia (chyba, że efekt ponownie zamierzony).

Co do pytania: w ORM tego nie zrobisz 1 sprytnym zapytaniem. Możesz pobrać obiekt użytkownika, a następnie tylko pierwszy element tablicy zdjęć poprzez $user->photos. Możesz też napisać zwykłe zapytanie (ręcznie lub poprzez Query Builder), które zwróci Ci dane w postaci tablicy lub obiektu (stdClass).

A czy warto stworzyć w SQL widok i na nim operować ? co będzie szybsze operacje na widoku czy przetwarzanie ręcznego zapytania ? I czy jeśli zdecyduje sie na widok to też muszę tworzyć plik php dla modelu odpowiedzialnego za widok ? Bo rozumiem, że wtedy operuję na tym widoku tak samo jak na zwykłej tabeli

Widoki zawsze będą wolniejsze od swojego odpowiednika w zwykłym zapytaniu SQL. Widoki stosuje się głównie w celu ograniczenia informacji dla użytkowników (np. ukrycie zarobków pracowników dla pewnych grup użytkowników). Osobiście jednak stosuję je również jako uproszczenie wykonywanych zapytań; narzut w związku z widokiem nie jest jakoś specjalnie odczuwalny, ale (jak już wspomniałem) widok będzie wolniejszy.

Czy tworzyć osobny model dla widoku? To już zależy od Ciebie. Nic nie stoi na przeszkodzie by tak właśnie uczynić. Pamiętaj tylko o odpowiednim nazwaniu widoku (w liczbie mnogiej) oraz odpowiednich nazwach pól dla kluczy obcych.