Есть ли на форуме программисты MS SQL щики

[toll]

Есть вопросы

[Petrovichtim]

задавай

[toll]

Petrovichtim

ок

1 запросы пишешь?

2 на Delphi (или другом языке) данные с ms sql вытягивал ... изменял ..

[Petrovichtim]

1 да пишу select* и тд))

2 Delphi обожаю)))

[Lucky]

давай уже, не томи...

[toll]

Petrovichtim

ок 1 вопрос :

конект к базе делаю через 1pod.udl .... поставил галочку сохранить пароль ... но при запуске моей программы пароль запрашивается... как сделать чтоб не запрашивался?

[Petrovichtim]

Понятия не имею о чём вы, я через ADO подключаюсь

[Lucky]

нужно поставить ADOConnection.LoginPrompt := false (по-умолчанию стоит true)

[toll]

Petrovichtim

дык и я по АДО

Lucky

помогло больше не просит паролей

[CooDi]

польше нету вопросов?

[toll]

CooDi

есть ... глобальный

есть 3 таблички ... А Б иС

А связана 1-многие с Б... Б связана 1-многие с С ... мне нужно выбрать данные с А и С ... если делаю методом "лопата"

where (A.id = Б.idA)and(Б.id = С.idБ)and(дата = .....)and(ююю) -тормозит жутко ... поидее должен быть способ сделать выборку последовательно

[CooDi]

это даже не SQL относится, а вообще к программированию. Сначала задай условия, отсекающие лишние записи А, потом выборка по А.id, затем отсекаем лишние В а потом выборка по B.id. и и т.д.

тоесть типа

where (A.data=....) and (A.id = Б.idA) and (Б.фамилия=...) and (Б.id = С.idБ) and (ююю).

может по синтаксису я и не правильно написал, но надеюсь общий смысл понятен. Это очень сильно уменьшает объем обрабатываемых данных.

[Lucky]

toll

Сдаётся мне, неспроста такие вопросы...

В общем, чтобы не тормозило, создавай индексы - даёт ну оооооочень большой скачок в производительности. Причём, индексы в таблицах должны соответствовать тем полям, по которым идёт сравнение (т.е., в том числе и составные индексы).

И можно воспользоваться разного рода соединениями через JOIN, например:

SELECT
    t1.FieldA, t3.FieldB
FROM
    Table1 t1 LEFT OUTER JOIN Table2 t2 ON t1.ID_t2 = t2.ID AND
    t2 LEFT OUTER JOIN Table3 t3 ON t2.ID_t3 = t3.ID

CooDi

Чтобы данные отсечь, их нужно сначала найти, а для этого и применяют индексы.

[toll]

Lucky

как работают viewsы, это динамические или статические таблицы

есть ли разница брать информацию с views или из таблиц...

[Lucky]

Views (вьюшки) - динамические представления данных.

Её состав определяется командой выборки данных (SELECT).

Вьюшка определена заранее, простой выбор из таблицы - более гибок. Кроме того, к вьюшке нельзя создавать индексы.

Основное назначение - отражение данных конечному пользователю (т.к. даёт доступ только на просмотр данных), т.е. через вьюшку данные нельзя изменить.

[toll]

Lucky

(я знаю одного лаки ... Петю ...)

про вьюшку я понял что это отражение данных ... вот вопроэ это отдельная табличка или же она создается в момент обращения и тогда проще сразу к таблицам обращаться

[Lucky]

---

Нет, Я не Петя.

---

Фраза "динамическое представление данных" разве не означает, что этот набор создаётся в момент обращения к представлению?

как работают viewsы, это динамические или статические таблицы

Ответ - динамические наборы данных (НЕ таблицы). Т.е., обращаясь к вьюшке за данными (например, SELECT * FROM View1) мы, по-сути, исполняем тот запрос, который её и формирует.

Например, пускай представление View1 определено как

SELECT * FROM Table1 WHERE Field3>100

Тогда запрос вида

SELECT * FROM View1

можно представить в виде следующего запроса:

SELECT * FROM (SELECT * FROM Table1 WHERE Field3>100) v1

Не помню, как насчёт MS SQL, но в Oracle есть материализованные представления (т.е. это вьюшки, у которых хранится результат в виде таблицы).

Через вьюшки обычно решается распределение прав доступа к тем или иным данным - кому попало давать права на просмотр всей таблицы нет необходимости. Поэтому, вьюшки являются неким инструментом в разграничении таких прав - мы даём пользователю права на просмотр вьюшки, а не всей таблицы, тем самым оберегая себя от непредвиденных последствий (вдруг тот окажется "прошаренным маньяком" и понапакостит в данных). Таким образом, исходя из соображений безопасности, конечному пользователю данные следует передавать посредством представлений, а внесение изменений осуществлять посредством процедур (т.е. исключить прямой доступ к данным).

А теперь, ВНИМАНИЕ, встречный вопрос: "В примере про JOIN я допустил ошибку. В каком месте?".

---

[genemy]

SELECT   t1.FieldA, t3.FieldB

FROM   Table1 t1

LEFT OUTER JOIN Table2 t2 ON t1.ID_t2 = t2.ID

AND t2 --это лишнее или тут условия не хватает

LEFT OUTER JOIN Table3 t3 ON t2.ID_t3 = t3.ID

Добавлено спустя 26 секунд:

через вьюшку данные нельзя изменить

можно иногда

[X-tender]

понапакостит в данных

Lucky, не совсем верно. Если роль позволяет лишь читать, то напакостить не сможет в таблице. Другое дело, что вьюха может представляют более ограниченный набор данных. Например, запретить пользователям просматривать информации не его уровня. Уровень будет в поле access_level. И вьюхи будут выбирать именно с определнным access level'ом.

[Lucky]

---

Конечно, ответ хотелось услышать от toll'a, но, что-то он молчит...

---

genemy

Да, ты прав, ЭТО лишнее.

И прав в том, что через вьюшки можно данные менять, что-то я подрастерялся малость...

---

X-tender

Я и имел в виду ограниченный набор данных.

Через вьюшки обычно решается распределение прав доступа к тем или иным данным - кому попало давать права на просмотр всей таблицы нет необходимости.

Да и явное ограничение по действиям пользователя определяется набором его прав (т.е., у одного пользователя может быть несколько ролей).

[toll]

Lucky

я не волшебник ... я только учусь

[X-tender]

Кстати про материализованные вьюхи, они как раз и служат в том числе и для того чтобы облегчить запросы, т.к. в них хранятся агрегированные записи. То есть если есть определенный диапазон данных запрашиваемых чаще прочего, а общий объем данных слишком велик, то сразу стоит подумать именно о них в качестве ускорения выборок. Помимо этого варьируя ее параметры обновления можно оптимизировать и под конкретные характеристики обновляемости самих данных. Например, нужно выводить топ 100 пользователей по количеству сообщений понедельно и в целом, а новые записи появляются в секунду по 100 штук, тогда создадим вьюху и установим ее обновление по запросу, а запрос будем выполнять еженедельно по планировщику.