Релации без seek

Как ли се оправят хората без този мощен инструмент? Значи имам таблица, всеки ред на която има уникален номер. В друга таблица, дадено поле съдържа този номер и се явява връзката между двете таблици. Със seek се извършва страшно бързо извличането на необходимия ред, а без него???

с други инструменти, а в краен случай - на ръка

ми, с джойн-ове... то за тва е SQL-а въобще. в крайна сметка, добре, за две таблици seek-овете вършат работа, обаче ако са 5 свързани? айде, няма да те плаша с 10 ;)

В каква база работиш и какъв език за
програмиране ползваш?

SQL-а се подразбира, но не е ли прекалено бавна операция за да измъкнеш само 1 ред?
Иначе пиша на c++ и ползвам access-ка база през ODBC (суровото api, без mfc класовете)

ako:
EBX e nomera v parvata tablica a primerno elementa e 4baita,
AAAA e adresa na tablicata,
MOV EAX,[EBX*4+AAAA]

:-)

Операцията не е бавна, защото SQL server-а използва индекс за да намери записа/записите. В твоя случай ODBC драйвера има грижата да преобразува SQL query-то до последователност от Seek/Read операции, в зависимост от базата данни.
Другото предимство, което ти дава ODBC-to е, че можеш да смениш базата данни (почти) без да променяш кода на програмата си. Така, че "цената", която плащаш като губиш малко performance(заради ODBC интерпретацията) си струва.
Разбира се - трябва да имаш съответните индекси :-)

да си кажа и аз скоромното мнение.. С ODBC метода sеек не бачка, не върви, абе забрави го. както те съветва Кромид ползвай старото и добро query от типа "select ....., from.... where ..." и отваряш един recordset с това query.

...да се претегли.
1. Ако в резултат на операциите очаквате скромен по размер рекордсет,
най добре си ползувайте технлогия seek. Ще бъде по ефективно.
Още повече пък, ако таблиците в които ровите, колкото и да са те,
не сьдържат достатъчно много records, та да "търчи човек напред-назад
като цветарка".
2. Е, ако ще работите с мащабни данни и едно query ви дава материал за
за много последователни дейности - то по-добре query. Само да не се
натътрузите като мен, преди време с проблеми от сорта bidirectionals.
3. Стори ми се, че подразбрах нещо за тактика, която условно ще я нарека
"отместване с указател". Хитро е. Правил съм го. Но много внимателската
при insert на данни, щото това дефакто си e техника на "псевдо индексиране"
(извинете за произволното окачествяване). Дали обаче спасява от индекси?
Засукана работа...
4. Убеден съм, че вьв всички случаи кадето има вторични ключове, някой
така или иначе е мислил за seek.