Ну, сложно сказать. Я думаю, зависит от квалификации, в первую очередь. И от стиля написания проекта.

Вкратце, коренные отличия ASE от ORACLE след.
Другая архитектура сервера. Есть понятие "база данных" (в оракле ближайший аналог - tablespace, хотя аналогия не полная), есть ОДИН
язык Transact SQL для всего, а не два, как в ORACLE - SQL и PL/SQL и одна виртуальная машина , которая его исполняет. Ну и все такое прочее.

TSQL , как говорят ораклисты, "гораздо беднее PL/SQL". Я бы сказал, что он лаконичнее, поскольку все навороты PL/SQL просто не нужны. Что самое интересное любой SELECT в хранимой процедуре "выводит" данные клиенту (казалось бы естественная штука, но в ORACLE почему-то такой возможности нет) .

ASE чистый блокировщик, и там нет реализации псевдоверсионности ORACLE, короче, писатель может заблокировать читателя и даже наоборот - читатель писателя.

ASE имеет две архитектуры таблиц - APL (all pages locking) и DOL ( data only locking), на последней архитектуре реализуются таблицы с row level locking. Это практически два парралельных мира, существующих врутри ASE, и их особенности надо учитывать при проектировании структуры БД.

Ну и т.п.

Поскольку ASE и MSSQL по архитектуре весьма похожи, а по ASE книг у нас нет (кроме древнего Хичкока), то я бы порекомендовал прочитать какую-нибудь книгу по MSSQL Server, лучше версии 6.0 или 6.5. , в качестве введения в архитектуру сервера и Transact SQL.

Ну и затем, если будут вопросы - писать сюда.

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


Это типа запрос на FAQ.
Попробую.

Сначала вкратце (пока маловато времени), на уровне эффектов. потом может еще что допишу, и в конце помещу в FAQ.

APL - all pages locking, классическая архитектура таблиц, используемая в ASE с момента его возникновения.

DOL - data only locking - новая архитектура таблиц, используемая в ASE с версии 11.9.2. Подразделяется на два (не очень отличающихся варианта) : data pages locking (DPL) и data rows locking (DRL).

*APLDOLВерсия ASEВСЕс 11.9.2Блокировка данных только страницы страницы или строкиБлокировка индексов транзакционная страниц индексов нетранзакционная (индексы блокируются не до конца транзакции) страниц и строк индексов по мере необходимостиПоддержка физического размещения данных (clustered index) поддерживается не поддерживаетсяРазмещение строк на странице данных всегда уплотненное не обязательно уплотненное (между записями могут быть "дырки").Изменяемость ROWID при изменении данных ROWID меняется ROWID остается постояннымОсобенности поддержки индексов в процессе транзакции индексы должны поддерживаться при перемещениях записей в БД индексы не требуют поддержки т.к. ROWID постоянныйОсвобождение незанятых страниц данных в процессе транзакции сборщиком мусора Влияние на приложения Скорость изменения данныхнизкаявысокаяВозможность парралельных неблокирующих вставок записейнетестьскорость "деградирования" таблиц низкая высокаястоимость чтения данных из таблицы ниже вышеВозрастание стоимости чтения при деградировании таблиц низкое высокоеНеобходимость поддержки данных (data maintanance) нет (т.е. низкая) естьВозможность физического перестроения таблицы в немонопольном режиме нет есть

Примечание: ROWID - внутренний идентификатор записи в ASE, имеющий смысл "адреса" записи в базе данных. Состоит из номера страницы и номера записи внутри страницы. Все ссылки на данны

teran
Зачем использовать блокировку на уровне всех страниц, если есть постраничная и построковая?


Ну, это достаточно просто . Классическая APL -структура таблиц более экономична в плане занимаемого таблицей пространства, требуемого количества чтений для выполнения читающего запроса и требуемого количества блокировок (напомню, что это - один из ресурсов сервера),
поскольку они на уровне страниц, а не строк. И кроме того, они требуют
меньше поддержцки, поскольку дефрагментация APL-таблиц потенциально ниже.
Так что обычно Sybase рекомендует для редко меняющихся таблиц и для OLAP-задач (DSS-задач) применять APL, а для интенсивного OLTP - DOL таблицы.

teran
Поддержка физического размещения данных (clustered index)

но получается что в DOL'е нельзя создать кластерный индекс? Тогда как у меня вроде есть :)


Я специально так написал "Поддержка физического размещения данных". Создать на DOL-таблице кластерный индекс действительно можно. Но :
1) Он не имеет структуру кластерного индекса, т.е. фактически является некластерным.
2) Данные в таблице не сортируются в порядке следования ключей в кластерном индексе.

А называется он кластерным только потому, что ASE пытается рамещать строки в таблице в соответствии с порядком этого индекса, в частности, при перестроении таблицы (reorg rebuild). Но при изменениях данных в таблице порядок следования записей может нарушаться.