 Автор |
Сообщение |
leoboec
Эксперт
 |
|
| воооо вот эжто наверное то что я и искал.... первичные и внешние ключи.... ! структуру то я уже нарисовал... но вот именно как связать этими ключами я не совсем понять могу.... |
|
 |
|
 |
AlexRock
Гуру
 |
|
| leoboec писал(а): |
| но вот именно как связать этими ключами я не совсем понять могу.... |
Отношения же (relations)! Я их делал с помощью мастеров и через оконный интерфейс, а можно всё на голом SQL (лично я не настолько крут, да и лень мне выписывать километры кода при создании БД - по кнопкам как-то привычнее пройтись).
А вообще, можно и без отношений - отдельные таблицы и всё. Только тогда тебе придётся либо триггеры писать, либо в логике твоего языка программирования данные вносить. У нас девушка вообще написала БД без отношений - просто по кнопке добавления записи в какую-нибудь таблицу, в подчинённые таблицы кодом тоже вносила записи - "ручками", как говорится. Хоть и плохой подход, но тоже, как говорится, вариант. |
|
| |
|
|
AlexRock
Гуру
|
|
| leoboec писал(а): |
| то есть пользователь видит сами таблицы |
Пользователь видит только то, что ты ему покажешь, если не полезет в файлы программные рыться. Под этим
| leoboec писал(а): |
| соответственно я их сходу ставлю visible= false и не напрягаюсь.. верно? |
ты, скорее всего, и имеешь ввиду мастера, который в твоей среде программирования за тебя генерирует код заполнения датагридов. Если у тебя настраивается отображение имеено так, то делай так. Лично я, если руками датагриды создаю, то просто не создаю в них вообще столбцов для данных, которые не хочу отображать - это же логично. Более того, если синхронизация сделана только в одну сторону (от сервера к клиенту), то как таблицу удалёнок, так и столбцы с датами добавлений-редактирований клиенту вообще можно не передавать, точнее, даже вообще их на клиентской БД не иметь. Т. е. кленитская БД у тебя будет без этого "обвеса", который у серверной есть (этот обвес - по сути, лишние данные для тебя и нужны только для синхронизации). |
|
| |
|
|
AlexRock
Гуру
|
|
| AlexRock писал(а): |
| Кстати, если при добавлении записи в таблицу заполнять каким-нибудь скриптом или триггером (чего там у вас с СУБД есть) столбец "Время последнего редактирования" тем же значением, что и в "Время добавления", то фактически при синхронизации с сервера можно не запрашивать столбец "Время добавления", ибо это будут те же данные, что и в столбце "Время последнего редактирования", т. е. всего два запроса придётся сделать - по столбцу изменений, и по столбцу удалений (в таблице удалёнок), вместо запросов по трём столбцам. Я сейчас так написал код, только ещё не протестировал. )) |
Щас протестировал - не получается. Всё таки, нужно разную логику для вставок и обновлений. Для вставок нужно сделать логику такую, чтобы в клиента вставлялись все данные вместе с ГУИДами, а для обновлений - все данные, но без ГУИДов, иначе если использовать одну и ту же логику что для вставок, что для обновлений, то при обработке обновлений будет попытка вставить данные с одинаковыми ГУИДами. В этом случае для таких новых вставок, для которых не делалось обновлений, придётся их данные два раза перекачивать - во время работы логики обработки вставок и во время работы логики обработки обновлений, но это меньшие затраты, чем пытаться для каждой обновлённой записи проверять, что она только обновлённая, а не вставленная с датой обновления, совпадающей с датой вставки. |
|
| |
|
|
|
Аватары: Вкл|Выкл ЮзерИнфо: Вкл|Выкл Подписи: Вкл|Выкл
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете вкладывать файлы
Вы можете скачивать файлы
|
|
