Database design question: True or False?

[IA72]

Это же каменый век, отлаживаться printf, intellicense нет, язык кобольих времен. Где, мля, Юкон наконец? Враги опять перенесли, на 2005.

Вот уже блин началось
Пошел миф что в Yukon можно писать порцедуры на c#, SQL можно не знать
Процедуры то писать можно. Какой нибудь перевод текста или обработка изображения, ради Бога
А вот если вместо одного реляционного оператора напишете как это обычно проход в цикле по записям, то никаких чудес в Yukon не будет, как и сейчас, это будет в 100-1000 раз медленнее

Еще боюсь что будут лепить процедуры на C#, и уже не скопируеш базу просто так backup на другой сервер, она будет тянуть DLL, ActiveX И прочую лабуду

Где написано, что можно не знать SQL? Вы мне свои мысли, пожалуйста, не приписывайте. Там внешние процедуры можно создавать. Это значит, что я могу свои библиотеки с усиленной бизнес логикой вынести на сервер с клиента (то, что раньше настолько геморройно было писать в t/sql). Могу нормально генерить эти самые процедуры через Code DOM из XML Schema, могу один и тот же код реюзать на клиенте и сервере (для offline работы, к примеру), могу криптографию, наконец, полноценно использовать, да много чего. Я еще раз повторю - программные средства MS SQL застыли на уровне 15-летней давности. В современные концепции программирования они не вписываются, поэтому народ и выносит все что можно в среднее звено/клиента. Архаика. Давно пора менять. Что касается быстродействия, то
"проход в цикле по записям" в процедуре, уже скомпилированной и загруженной в памятьв зависимости от ситуации может быть быстрее,
чем оператор "select where".

А что до администраторов, так меня, э, их заботы не волнуют

[Dmitry67]

По поводу когда цикл быстрее пиведите пример PLS
Что касается архаичности, то конечно SQL в наше объектно ориентированное время странен, однако есть ОЧЕНЬ серьезные причны для этого
В частности они привели к краху всех ОО баз
Но это уже обсуждалось

[IA72]

По поводу когда цикл быстрее пиведите пример PLS
Что касается архаичности, то конечно SQL в наше объектно ориентированное время странен, однако есть ОЧЕНЬ серьезные причны для этого
В частности они привели к краху всех ОО баз
Но это уже обсуждалось

Когда, к примеру, надо прервать выполнение по каким-то соображениям.
К примеру, у вас есть много адресов, по которым надо отправить почту.
Или есть данные, которые надо расшифровать.
При ошибке это дело надо прекратить немедленно. Если я буду это делать в цикле, то существует ненулевая вероятность, что мне не придется обрабатывать поток записей до конца, в противном случае я а) теряю время на передачу данных б) Сервер отрабатывает весь запрос независимо
Ну и еще можно придумать. Собственно, мне кажется что либо я не совсем точно выразился, либо вы перечитали книжек по объектным базам.
Мне не кажется SQL архаикой. Он, кстати, должен остаться, я только за.
Мне кажется T/SQL архаикой. А вот он должен уйти. Из того, что я видел, разработчики объектных баз пытались выкинуть SQL, а этого делать не надо.
Запросы должны быть.
То есть, select * from Foo должен возвращать массив объектов foo (soap), и это уже практически есть.
where foo.id='bar' тоже должно работать, но id это не поле, а свойство объекта.
Серверу вполне по силам рядовой случай, когда это свойство просто хранилище безо всякой логики отработать его с той же скорость, с какой он сейчас отрабатывает поля.
update foo set foo.FooBar = 'FooBar' аналогично.
Разница в том, что при создании класса можно написать
class Foo{
string FooBar {
set{ if value == 'BadValue' throw new Exception()}
get{;}
}
}

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

[Victor]

Там внешние процедуры можно создавать. Это значит, что я могу свои библиотеки с усиленной бизнес логикой вынести на сервер с клиента (то, что раньше настолько геморройно было писать в t/sql).

Их очень давно можно было писать. Называются extended stored procedures.

...когда приходится переключаться из VS.NET или Delphi в Query Analyzer или SQL Navigator, тошнит...
...
Но по крайней мере для MS SQL такие, что проще printf.
...
Мне кажется T/SQL архаикой.

"Вы просто не умеете их готовить"

[Sabina]

Ну и как Вам?

Вот могу еще предлоить от одного из наших ярых противников foreign keys:

Quote:
It has been observed that you are not fond of foreign keys. And I have heard tell that Dick Wilmot is of a similar disposition. I think that it is time that the class entertains this discussion.

Me? I never liked pointers which "pointed to" garbage. I see a certain similarity between dangling pointers and loose referential integrity. In short, I use foreign keys because it is sort of the done thing and I probably don't know any better.

Reply:
A (ONE) foreign key in a relation (mathematical term for table) implies a 1:N relationship. In the canonical employee, department tables the existence of a
department number or department ID column in the employee relation does not just imply that an employee can only be a member of 1 department at-a-time but also enforces this constraint. The database designer would, with such a design, usurp the prerogatives of the HR vice-president and prohibit a part-time employee from working in two different departments. I would caution database designers from employing foreign keys in this and many other circumstances even after the responsible officers or managers have sworn that an M:N relationship will never exist between entities. The programmers and database crew may be there long
after those swearing have been promoted, terminated or retired.

For further details see: Wilmot, R. B. “Foreign keys decrease adaptability of database designs”, Communications of the ACM 27, #12, December 1984.

This position was loudly denounced by a consultant and author named CJ Date
and I was denounced by other party members for having the gall to make any
writing not blessed by the holies.

Some have gotten past the religious issues more to the heart of the matter:

> Relationships can be represented either by using foreign keys or constructing new relations. The exact representation depends on the type of the relationship and its associated min-max cardinalities. In a general sense, a functional relationship can be represented using foreign keys; a new relation is not necessary. If the relationship is not a function, then a new relation should be created. Note that, whenever a relationship can be represented using foreign keys, an alternative representation of creating a new relation is always possible [Wilmot 1984]. In general, the converse is not true.

from ACM TODS Dec. 1999 pp. 453-486 Dey, D, Storey, V and Barron, T.
"Improving Database Design through the Analysis of Relationships"

Another downfall of foreign keys is dynamism and mutability of enterprise
structures.

> It is generally believed that a well-designed Conceptual Schema will remain stable over time. However, current literature rarely addresses how such stability should be observed and measured in the operational business environment with evolving information needs and database structures.

from Lex Wedemeijer _*Lecture Notes in Computer Science_
*
*Volume 2065 / 2001 **Chapter:* p. 220
"*Defining Metrics for Conceptual Schema Evolution"

The employee - department schema can be made flexible by
introducing an employed_in table that models relationships
between employees and departments.

Сабина

[Victor]

A (ONE) foreign key in a relation (mathematical term for table) implies a 1:N relationship.

FK всего лишь гарантирует, что отношение валидно. Та же самая структкра без FK не сможет поддерживать отношение многие-ко-многим . Так-же никто не мешает реализовать многие-ко-многим с FK.

Another downfall of foreign keys is dynamism and mutability of enterprise structures.

Другими словами "сковывает свободу действий кривых и шаловливых ручёнок"

У меня сложилось впечатление, что чем сильнее речь человека страдает "наукообразием", тем меньше стоит прислушиваться к его советам. По крайней мере, по техническим вопросам.

[Sabina]

Решила написать что я сама по этому поводу думаю, а то по-моему создалось впечатление, что мое мнение совпадает с мнением человека, цитату из которого я привела.

A (ONE) foreign key in a relation (mathematical term for table) implies a 1:N relationship. In the canonical employee, department tables the existence of a
department number or department ID column in the employee relation does not just imply that an employee can only be a member of 1 department at-a-time but also enforces this constraint. The database designer would, with such a design, usurp the prerogatives of the HR vice-president and prohibit a part-time employee from working in two different departments. I would caution database designers from employing foreign keys in this and many other circumstances even after the responsible officers or managers have sworn that an M:N relationship will never exist between entities. The programmers and database crew may be there long
after those swearing have been promoted, terminated or retired.

Все это говорит мне только о том, что надо имплементировать FK аккуратно, а вовсе не о том, что они вообще не нужны.

Relationships can be represented either by using foreign keys or constructing new relations. The exact representation depends on the type of the relationship and its associated min-max cardinalities. In a general sense, a functional relationship can be represented using foreign keys; a new relation is not necessary. If the relationship is not a function, then a new relation should be created. Note that, whenever a relationship can be represented using foreign keys, an alternative representation of creating a new relation is always possible [Wilmot 1984]. In general, the converse is not true.

Мне не совсем понятно что имеется в виду под "Relationships can be represented either by using foreign keys or constructing new relations." Если это о промежуточной таблице, типа employed_in, описанной внизу , то см.комментарий ниже.

It is generally believed that a well-designed Conceptual Schema will remain stable over time. However, current literature rarely addresses how such stability should be observed and measured in the operational business environment with evolving information needs and database structures.

Опять где тут автор призывает "не использовать FK"? И никаких ссылок на эту самую current literature нет, кроме того что мужик сослался на свою статейку 84 года свежести.

The employee - department schema can be made flexible by introducing an employed_in table that models relationships between employees and departments.

А разьве в этом случае не придется делать два SELECT-а вместо одного, если нужно вытащить детали по департментам, если известно user_id? В смысле актуальны ли тогда вообще JOIN-ы при таком раскладе?

Сабина

[IA72]

Там внешние процедуры можно создавать. Это значит, что я могу свои библиотеки с усиленной бизнес логикой вынести на сервер с клиента (то, что раньше настолько геморройно было писать в t/sql).

Их очень давно можно было писать. Называются extended stored procedures.

Знаю. Небезопасно и гемморойно, а через xp_cmdshell медленно.

...когда приходится переключаться из VS.NET или Delphi в Query Analyzer или SQL Navigator, тошнит...
...
Но по крайней мере для MS SQL такие, что проще printf.
...
Мне кажется T/SQL архаикой.

"Вы просто не умеете их готовить"

Возможно, но зачем я должен уметь их готовить? Почему вообще эта разница нужна? Я, собственно, об этом и говорю - архаика. Это не значит что t-sql плохой язык. Это как Кобол, хороший но древний. Сам по себе - никаких проблем. Интеграция в современные системы - как конь и трепетная лань. На свалке истории ему место.

[Dmitry67]

Слишком много надо тянуть для совместимости
Да и замены нормальной пока нет
Что нибудь ОО но чтобы работать с множествами

process Object.SomeProperty where Condition
и this будет множеством

[Victor]

"The employee - department schema can be made flexible by introducing an employed_in table that models relationships between employees and departments."

А разьве в этом случае не придется делать два SELECT-а вместо одного, если нужно вытащить детали по департментам, если известно user_id? В смысле актуальны ли тогда вообще JOIN-ы при таком раскладе?

Сабина

Насколько я понимаю это классический способ реализации many-to-many при помощи третей таблицы

Что-то типа

CREATE TABLE Departments
(
Department_ID int,
Name varchar(255)
)

CREATE TABLE Emploees
(
Emploee_ID int,
Name varchar(255)
)

CREATE TABLE Departments_Emploees
(
Emploee_ID int,
Department_ID int
)

SELECT Emploees.Name, Departments.Name
FROM Emploees
JOIN Departments_Emploees ON Emploees.Emploee_ID = Departments_Emploees.Emploee_ID
JOIN Departments ON Departments.Department_ID = Departments_Emploees.Department_ID

Соответственно
SELECT Departments.Name
FROM Departments_Emploees JOIN Departments ON Departments.Department_ID = Departments_Emploees.Department_ID
WHERE Departments_Emploees.Emploee_ID = @Emploee_ID




Разумеется в этой ситуации хорошо бы создать FK для
Departments_Emploees.Department_ID -> Departments.Department_ID
и Departments_Emploees.Emploee_ID -> Emploees.Emploee_ID