Да, немного. А ты про embedded SQL ? :)
Да, слышал лет 10 назад этим ещё пользовались :-)
Насколько я понимаю, LINQ - это постановка задачи наоборот - берём программу
на 'нормальном' языке (C#, C++ etc) и позволяем работать с данными, но без
датасетов,
а с конструкциями этого языка. Не нравится... MS хочет взять под свои крылья
всех
чайников и дать им возможность назвать себя программистами. Иными словами -
опустить порог входа в профессию до нуля. Я не хочу иметь такую профессию. И я,
по этой причине, давно не переношу VB\Access и т.п.
Ну что-то типа того, только вот я так и не понял почему это плохо... Они
же со временем смогут в датасеты те же индексы прикрутить и прочую
лабуду, сделать движок БД иными словами.
Это не интеграция. Это профанация. Всё спрятано. Шаг влево, шаг вправо -
расстрел.
Или ничего не работает. Всё в стиле МС - они лучше знают, что тебе нужно.
Ну этого я не знаю. Думаю не так всё там уж и плохо. Во всяком случае с
виду оно SQL напоминает.
Есть такой тип данных, как record. Дальше объяснять ? :)
О, так это ж и есть интерфейс урезанный :-)
Как имя таблицы в процедуру передешь без интерфейсов?
А вот этого не надо.
А наследование таблиц мне лично кажется тоже ненужным, а вот реализация
интерфейсов очень полезной могла бы быть.
Интерфейсы хороши в других местах. Пока не понятно зачем в БД методы,
интерфейсы точно также не понятны.
Ну ты пользуешься шаблоными в C++? Думаю пользуешься ;-) Я просто C++ не
люблю и не помню как там уже сделано. В С# есть такое понятие как
уточнение параметра, т.е. я объявляю параметрический метод и потом ниже
уточнаю что тип этого параметра должен реализовывать такие-то интерфейс
(в нашем случае пусть это будет тип record). Ну и все дела. Потом я в
при выхове процедуры в качестве параметра могу указать любую таблицу,
которая совместима с этим типом record.
Зачем нужны методы и интерфейсы? Ну тут придумать можно массу случаев.
1) Логическая группировка методов (возможно это схемы делают - я не в
курсе). Например есть у вас процедуры для расчёта статистики. Было бы
удобно обэединить их как статические методы объекта Statistics и
вызывать их как-то так:
EXECUTE PROCEDURE Statistics.GetMonthStatistics(...)
EXECUTE PROCEDURE Statistics.GetWeekStatistics(...)
2) Многие процедуры в базе по своей сути являются приватными и
предназначены лишь для вызова из других процедур. ООП эту проблему
решает очень просто: private/public и все дела.
3) Если запись можно представить в виде интерфейса, то для этой записи
можно и метод вызвать. У меня в базах пруд пруди процедур, которые
предназначены для вызова с входными параметрами из записи одной и той же
таблицы, например:
DECLARE MyNews INews;
FOR SELECT * FROM News INTO :News DO
BEGIN
MyNews.Refresh();
IF (MyNews.PublishDate < 'YESTERDAY') THEN
MyNews.Delete();
END
а внутрях Refresh и Delete будут доступны значения всех полей записи
типа INews.
4) Тему можно развивать например событиями. Триггеры - такая хрень,
которая вызывается всегда. А мне очень часто такое не нужно. Но это меня
уже понесло. Так от существующего сервера камня на камне не останется :-)))
