Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 28 29 30 31 32 [33] 34 35 36 37 .. 75   вперед  Ctrl
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ
locky
Это когда "очень удобно реализовывать обработку данных на стороне клиента/промежуточного звена"?

На стороне любого звена, которое ломится на тот или иной SQL-сервер.


А на стороне самого сервера - можно?
3 фев 09, 11:06    [6771039]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)
Как один из вариантов, делаются процедуры-обвязки, вызывающие commit (или rollback если прилетело исключение).
skip
Повторю, это ОДИН ИЗ возможных вариантов

Про этот вариант я знаю (он мне не сильно нравится)
Если существуют еще кошерные варианты/методы - делитесь. Не глума ради - и просто интересно, и пригодится, наверное.


Еще есть вариант commit-ов с клиента. Тоже не всем нравится.
В общем нужно просто принять, что begin/end не имеет к транзакциям никакого отношения.
Это не хорошо и не плохо - это просто есть
3 фев 09, 11:12    [6771081]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Tapac
Member

Откуда: Альметьевск
Сообщений: 100
Eugenkru1
Tapac,
Посмотри строчку:
SQLEXEC(nh, "SELECT ID FROM test WHERE data='test text'" + REPLICATE('-', n))
мне абсолютно не нравится надпись: data='test text' + REPLICATE('-', n)
У тебя поле к примеру ограниченно 10 знаков и твои минусы в хвосте отрубятся не доходя до этапа кэширования и как сработает SQL оракла мы не знаем.
Не мог бы ты как админ примерчик по убедительнее изобресть?


Евгений, символы комментариев Oracle "--" добавляются в текст запроса, а не к искомой строке, так что длина поля test.Data никак не влияет на результаты данного текста запроса. Будьте внимательны, не торопитесь.

Как "сработает SQL оракл" на самом деле известно, потому что подробно описано в документации Oracle. Но т.к. у меня, откровенно говоря, нет желания и времени для Вас искать ссылки в документации, я просто изменю код теста, чтобы текст запроса каждый раз был новым.

SET SAFETY OFF
SET TALK OFF

n = 100
nh = SQLCONNECT( "test", "test", "test")

s0 = SECONDS()
FOR i=1 TO n
	SQLEXEC(nh, "SELECT ID FROM test WHERE data='"+SYS(2015)+"'" )
ENDFOR
s = SECONDS()

? 'Общее время выполнения:' + LTRIM(STR(s-s0,8,7))
? 'Среднее время поиска:' + LTRIM(STR((s-s0)/n,8,7))

Результаты "локального" теста на 100 млн.записях:
Среднее время поиска в FoxPro: 0.05579
Среднее время поиска в Oracle (без кэширования): 0.00172
3 фев 09, 11:22    [6771177]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Егоров Александр
Member

Откуда: Хабаровск
Сообщений: 517
Sergey Orlov
ребята, а мне честно говоря пофиг ваши измерения скорости, мне в SQL-варианте важны другие составляющие, например, чтобы базу никто не спер, ну и другие.


Это синтетический тест. Выборка единственного значения из единственной таблицы с единственным столбцом. Тест демонстрирует только лишь зависимость падения скорости выборки от объема данных в файл-серверных системах и разницу этой зависимости между клиент-серверными системами. Падение скорости на два порядка при росте данных на два порядка же - это нормально для файл-сервера, что неудивительно ни для кого, кроме избранных. :)
Для обеспечения безопасности базы в файл-серверном варианте нет никаких инструментов. Для файл-серверных баз полный доступ ко всей базе - обязательное условие.
Для обеспечения логической целостности опять же нет никаких инструментов. Обеспечение целостности ложится полностью на программиста. Что опять таки понятно всем, кроме избранных. Не говоря уже о том, что это потребует обеспечения бесперебойной работы не только одного сервера, но и всех клиентских мест.
3 фев 09, 11:31    [6771260]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Сахават Юсифов
Попробуй ка загони в ОРМ.

Не вижу сложности. Саха, Вы и так себя зарекомендовали как раскуриватель "старых" подходов в разработке решений. Дискутировали с Вами не раз. Не нарывайтесь (по доброму)

locky

На стороне клиента я отображаю, осуществляю ввод и первичную проверку.
Но уж никак не "обработку".

А с обработкой в чем сложности? SQLCLR если на то пошло. Всё транзактом не ришить. А сорить в БД тысячами "хранимок"... Кстати, как у Вас с документированностью решений, поведайте нам?
Я уже предвижу Ваш ответ. Ибо плавали...

locky
С чего вы взяли про велосипеды?
Это, простите, у вас, насколько я понимаю, при изменении структуры данных заодно меняется и структура классов.

1. А что Вы хотели? Сломать фундамент и курить в сторонке?
2. Ломать фундамент - значит очень плохая аналитика. Почитайте на досуге методологии MSF, RUP. Посмотрите на процессы разработки решений, проектные команды, и т.д. Ломать - не строить.
3. Если уж сломали - нужен, разумеется, перекомпил клиента БД (клиент пользователя, веб-сервис, SQLCLR, и т.д.) + изменения в проектной документации + изменения в постановке + изменения в спецификации к решению.
4. А у Вас всё просто. Подправил ручками базу - и вуаля Вот так и работаее "на коленке", да? :)
5. Серьезно. Я уже не раз читаю Ваши посты и замечаю некоторую "неподкованность" (извините) в методологиях и постановке. У Вас одна цель - подправить ручками и всё полетело. Это в корне неверно. Отсюда и бардак. А я уверен, что у Вас бардак. Ибо, плавали :)

locky
У меня всё банальнее - об изменении структуры данных клиент вообще не знает (да ему и плевать глубоко на то, что делается на стороне сервера).

Описал выше. Всё не так просто, как Вам кажется. Наколенную разработку решений мы все когда-то проходили...
locky
Да и самой серверной стороне - тоже глубоко плевать на изменение структуры данных.
И всё это по строгим канонам без всяких излишеств. Реюзабельно. Сопровождаемо. Изолировано.

Документировано? Сопровождаемо - оно у всех сопровождаемо. Изолировано - ничерта не изолировано у Вас.

locky
Если дров много перерублено - значит, не всё там однозначно. И значит, моя т.з. - является достаточно обоснованной и распространённой.

Неправда. У Вас нет обоснований, т.к. Вы не работали с этим и не знаете тонкостей. Я же не зря про озарения сказал :)

locky
зы а за озарением я пойду к Свидетелям Иеговы

Упаси Бог Вас от этой секты

locky

А на стороне самого сервера - можно?

Можно. SQLCLR
3 фев 09, 11:32    [6771272]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Егоров Александр
Sergey Orlov
ребята, а мне честно говоря пофиг ваши измерения скорости, мне в SQL-варианте важны другие составляющие, например, чтобы базу никто не спер, ну и другие.


Это синтетический тест. Выборка единственного значения из единственной таблицы с единственным столбцом. Тест демонстрирует только лишь зависимость падения скорости выборки от объема данных в файл-серверных системах и разницу этой зависимости между клиент-серверными системами. Падение скорости на два порядка при росте данных на два порядка же - это нормально для файл-сервера, что неудивительно ни для кого, кроме избранных. :)

Можно согласиться. Но при этом на средних базах скорость работы FoxPro выше.

Егоров Александр
Для обеспечения безопасности базы в файл-серверном варианте нет никаких инструментов. Для файл-серверных баз полный доступ ко всей базе - обязательное условие.

А это абсолютно не так. И скорей предмет организации работы, чем самой базы данных.
У меня и к серверной базе может быть полный доступ, и к файл-серверной – неполный.

Егоров Александр
Для обеспечения логической целостности опять же нет никаких инструментов. Обеспечение целостности ложится полностью на программиста. Что опять таки понятно всем, кроме избранных. Не говоря уже о том, что это потребует обеспечения бесперебойной работы не только одного сервера, но и всех клиентских мест.

Извините, вы просто не в курсе. Все инструменты есть. Но надежность серверных систем выше.
3 фев 09, 11:41    [6771351]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Tapac
Member

Откуда: Альметьевск
Сообщений: 100
Eugenkru1
Tapac,

....
Значение можно написать даже data=SYS(2015) но сам запрос остаётся неизменным и оракл будет по любому использовать кэширование - это очевидно. Я не верю что фокс выигравший у оракла на 1 милионе записей будет проигрывать на 100 милионах. На мой взгляд тут дело просто в кэшировании повторяющихся запросов в твоём примере.


Евгений, обращаю Ваше внимание по взаимосвязанные понятия в серверах БД:
план запроса (существует также в FoxPro);
хинт и не-SQL управление планом запроса (отсутствует в FoxPro);
кеш планов и кеш данных (мне ничего не известно об этом в FoxPro);
претранслированные запросы (отсутствуют в FoxPro), не путать с функцией SQLPREPARE() в FoxPro.

Не торопитесь, внимательно почитайте документацию любого сервера БД, запрограммируйте пару примеров самостоятельно с применением любого доступного сервера БД. Сравните.
Не торопитесь делать публичные выводы.

P.S. "Выигрыш" FoxPro в 0.00002 сек в ОДНОМ очень узкоспециализированном тесте -- не выигрыш. Евгений, еще раз повторю, я сделал тест для ВАС, не для того чтобы показать превосходство одной технологии над другой (какой смысл сравнивать мокрое с треугольным?), а для того чтобы ВЫ задумались и увидели что-то, кроме FoxPro.
3 фев 09, 11:42    [6771363]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Tapac

"Выигрыш" FoxPro в 0.00002 сек в ОДНОМ очень узкоспециализированном тесте -- не выигрыш. .


Tapac,
не только в одном узкоспециализированном. На фоксклубе постоянно обсуждаются подобные вопросы. Все давно проверено и известно.
Все, кто хотел, уже научились грамотно пользоваться и FoxPro, и связкой FoxPro+сервер (SQLServer, Oracle и т.д.).
3 фев 09, 12:00    [6771496]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Егоров Александр
Member

Откуда: Хабаровск
Сообщений: 517
Я бы сказал скорость работы FoxPro выше на простых и однопользовательскиз выборках. Даже, наверное, значительно выше.

Fox5631
Егоров Александр
Для обеспечения безопасности базы в файл-серверном варианте нет никаких инструментов. Для файл-серверных баз полный доступ ко всей базе - обязательное условие.

А это абсолютно не так. И скорей предмет организации работы, чем самой базы данных.
У меня и к серверной базе может быть полный доступ, и к файл-серверной – неполный.

Пример. Таблица Payments (id int, DocShip int, DocPay int, PaySumm money). Соответственно одна Payments.dbf. как сделать так, чтобы user1 не имел возможности ни в каком виде получить информацию по столбцу PaySumm? В отлиции от пользователя user2?

Fox5631
Егоров Александр
Для обеспечения логической целостности опять же нет никаких инструментов. Обеспечение целостности ложится полностью на программиста. Что опять таки понятно всем, кроме избранных. Не говоря уже о том, что это потребует обеспечения бесперебойной работы не только одного сервера, но и всех клиентских мест.

Извините, вы просто не в курсе. Все инструменты есть. Но надежность серверных систем выше.

Может быть и не в курсе. Файл-серверные решения не применяю уже давно. Тогда скажите, как эти инструменты решают пробелему, если один из клиентов начинает записывать транзакцию в несколько физических таблиц и происходит обрыв связи. Примеров с получасовыми "ждите, идет переиндексация" знаю немало, если Вы подскажете такой инструмент - буду только рад.
3 фев 09, 12:08    [6771566]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Fox5631
Guest
Егоров Александр

Пример. Таблица Payments (id int, DocShip int, DocPay int, PaySumm money). Соответственно одна Payments.dbf. как сделать так, чтобы user1 не имел возможности ни в каком виде получить информацию по столбцу PaySumm? В отлиции от пользователя user2?

Вы хотите сказать, что встроенными средствами самой СУБД это не сделать. Правильно я вас понял?
Но это не значит, что этого не сделать в принципе. И это делается.

Егоров Александр

Может быть и не в курсе. Файл-серверные решения не применяю уже давно. Тогда скажите, как эти инструменты решают пробелему, если один из клиентов начинает записывать транзакцию в несколько физических таблиц и происходит обрыв связи. Примеров с получасовыми "ждите, идет переиндексация" знаю немало, если Вы подскажете такой инструмент - буду только рад.


Я выше уже приводил пример того, как и при работе с SQLServer теряются данные из-за плохой работы оборудования. Прочитайте весь топик.
3 фев 09, 12:15    [6771640]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Gluk (Kazan)
Еще есть вариант commit-ов с клиента. Тоже не всем нравится.

Клиент по определению - глючный, поэтому это и правда не нравится.
3 фев 09, 12:42    [6771870]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Егоров Александр
Пример. Таблица Payments (id int, DocShip int, DocPay int, PaySumm money). Соответственно одна Payments.dbf. как сделать так, чтобы user1 не имел возможности ни в каком виде получить информацию по столбцу PaySumm? В отлиции от пользователя user2?

Простите, а как средствами сервера Вы это сможете сделать?
На ум приходит только решения средствами серверных DDL триггеров. Но, что-то я не припомню, чтобы можно было DDL триггерами контролировать процесс селекта "по полям". Либо можно селектовать, либо нельзя. Или я ошибаюсь?
3 фев 09, 12:44    [6771893]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)
Еще есть вариант commit-ов с клиента. Тоже не всем нравится.

Клиент по определению - глючный, поэтому это и правда не нравится.


Дык транзакции для того и придуманы, чтобы с этой глючностью бороться :)
3 фев 09, 12:48    [6771933]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ
1. А что Вы хотели? Сломать фундамент и курить в сторонке?

2. Ломать фундамент - значит очень плохая аналитика. Почитайте на досуге методологии MSF, RUP. Посмотрите на процессы разработки решений, проектные команды, и т.д. Ломать - не строить.
[/quot]
Кто ломал фундамент? Где?
Или вы считаете, что расширение списка/состава атрибутов - есть "ломка фундамента"?
Ну, не знаю, м.б. в случае ORM так и есть (ведь придётся, наверное, переделывать классы етк).

МСУ

4. А у Вас всё просто. Подправил ручками базу - и вуаля Вот так и работаее "на коленке", да? :)
5. Серьезно. Я уже не раз читаю Ваши посты и замечаю некоторую "неподкованность" (извините) в методологиях и постановке. У Вас одна цель - подправить ручками и всё полетело. Это в корне неверно. Отсюда и бардак. А я уверен, что у Вас бардак. Ибо, плавали :)

Угу. Внесение изменения в базу - это "на коленке", "ручками".
А внесение изменения и в базу и в клиента/клиентские классы - это, оказывается, кошер, методология, не-бардак, в корне верно...
И, что самое главное - летает!

МСУ
Описал выше. Всё не так просто, как Вам кажется. Наколенную разработку решений мы все когда-то проходили...

Ессно, если по изменению структуры БД мне необходимо вносить изменения в еще тыщу разных мест на клиенте - то "всё не так просто", кто бы спорил.

МСУ

Документировано? Сопровождаемо - оно у всех сопровождаемо. Изолировано - ничерта не изолировано у Вас.

Изолированно, друг мой, изолированно


МСУ

locky

А на стороне самого сервера - можно?

Можно. SQLCLR

Нда. Гоняем данные из БД в CLR и обратно, чтобы в одном месте - выбрать, во втором - собрать, снова выгнать запрос, снова получить данные, обработать, результат вернуть... Такое методологие, наверное, и правда - нужно всецело документировать и т.д. - ибо можно будет и ноги и голову поломать, пытаясь потом разобраться....
3 фев 09, 12:49    [6771944]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Gluk (Kazan)
Дык транзакции для того и придуманы, чтобы с этой глючностью бороться :)

Не-не-не...
Клиент, к примеру, может банально не сделать коммит - последствия не нужно перечислять?
Или не сделать роллбэк...
3 фев 09, 12:50    [6771951]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)
Дык транзакции для того и придуманы, чтобы с этой глючностью бороться :)

Не-не-не...
Клиент, к примеру, может банально не сделать коммит - последствия не нужно перечислять?
Или не сделать роллбэк...


Не нужно :) SMON сделает rollback
3 фев 09, 12:51    [6771971]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Gluk (Kazan)
Не нужно :) SMON сделает rollback

Зависит от...
это если исключение вырвалось за верхний блок.
а если исключение не вырвалось, но ни коммита ни ролбэка не было?
3 фев 09, 12:54    [6771988]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
МСУ

Локи, RTFM. Когда придет озарение - тогда и поговорим. На эту тему уже много дров перерублено. Серьезно.
...
Я уже не раз читаю Ваши посты и замечаю некоторую "неподкованность" (извините) в методологиях и постановке. У Вас одна цель - подправить ручками и всё полетело. Это в корне неверно. Отсюда и бардак. А я уверен, что у Вас бардак. Ибо, плавали :)
...

А я уверен, что бардак у Вас.

Давайте не раскидывать пальцы веером и не считать что знаете как надо делать лучше других.
3 фев 09, 12:54    [6771990]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Подпольщик
Guest
locky, клиент может угробить любую идею и свести на нет приемущество любой СУБД.
1С тот же взять.
3 фев 09, 12:57    [6772024]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4508
Fox5631
Егоров Александр

Пример. Таблица Payments (id int, DocShip int, DocPay int, PaySumm money). Соответственно одна Payments.dbf. как сделать так, чтобы user1 не имел возможности ни в каком виде получить информацию по столбцу PaySumm? В отлиции от пользователя user2?

Вы хотите сказать, что встроенными средствами самой СУБД это не сделать. Правильно я вас понял?
Но это не значит, что этого не сделать в принципе. И это делается.

Ну и как это делается на фоксе в файл-серверном варианте, расскажите пожалуйста...
Т.е. я имею возможность читать файл user.dbf, но не могу прочитать столбец passwd в нем...
Fox5631

Егоров Александр

Может быть и не в курсе. Файл-серверные решения не применяю уже давно. Тогда скажите, как эти инструменты решают пробелему, если один из клиентов начинает записывать транзакцию в несколько физических таблиц и происходит обрыв связи. Примеров с получасовыми "ждите, идет переиндексация" знаю немало, если Вы подскажете такой инструмент - буду только рад.


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

Ваш пример, когда грохается жесткий диск сервера, не является показательным, давайте посмотрим пример, вот когда рвется коннект с сервером у одного клиента
При файл-серверном варианте, может возникнуть ситуацию, когда в одну таблице вы данные уже записали, а в связанную нет и что мы будем иметь в базе? И что увидят другие клиенты...
В случае SQL-сервера вы пишите в базу транзакцию, обрыв коннекта для сервера это откат транзакции, целостность базы при этом не нарушена и этого сбоя другие клиенты не видят.
3 фев 09, 12:59    [6772050]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Gluk (Kazan)
Не нужно :) SMON сделает rollback

Зависит от...
это если исключение вырвалось за верхний блок.
а если исключение не вырвалось, но ни коммита ни ролбэка не было?


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

Если программист забыл commit (в ХП или на клиенте не суть), кто виноват ???
Если соединение оборвалось - транзакция откатывается также без вопросов
Если прилетело (или недолетело) исключение - поведение также детерминировано

Оно непривычно после перехода с MS SQL, но кто сказал, что именнно там все правильно и максимально удобно ???
3 фев 09, 13:04    [6772104]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
проходящий.
Guest
Sergey Orlov

Ваш пример, когда грохается жесткий диск сервера, не является показательным, давайте посмотрим пример, вот когда рвется коннект с сервером у одного клиента
При файл-серверном варианте, может возникнуть ситуацию, когда в одну таблице вы данные уже записали, а в связанную нет и что мы будем иметь в базе? И что увидят другие клиенты...
В случае SQL-сервера вы пишите в базу транзакцию, обрыв коннекта для сервера это откат транзакции, целостность базы при этом не нарушена и этого сбоя другие клиенты не видят.

Ребяты!!! Ну сколько раз и как вам всем надо повторить, что уже есть в фоксе транзакции, есть. Ведь выдержки из доки по фоксу для вас не аргумент. А что тогда аргумент?
То, что вы не представляете как это сделано не означает их отсутствия или неработы.
3 фев 09, 13:04    [6772105]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
проходящий.
Sergey Orlov

Ваш пример, когда грохается жесткий диск сервера, не является показательным, давайте посмотрим пример, вот когда рвется коннект с сервером у одного клиента
При файл-серверном варианте, может возникнуть ситуацию, когда в одну таблице вы данные уже записали, а в связанную нет и что мы будем иметь в базе? И что увидят другие клиенты...
В случае SQL-сервера вы пишите в базу транзакцию, обрыв коннекта для сервера это откат транзакции, целостность базы при этом не нарушена и этого сбоя другие клиенты не видят.

Ребяты!!! Ну сколько раз и как вам всем надо повторить, что уже есть в фоксе транзакции, есть. Ведь выдержки из доки по фоксу для вас не аргумент. А что тогда аргумент?
То, что вы не представляете как это сделано не означает их отсутствия или неработы.


Да в общем то никому не интересно есть ли в фоксе транзакции (это личное дело фокса)
Интересно обеспечивается ли ACID ???
3 фев 09, 13:06    [6772128]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Yo.!
Guest
Gluk (Kazan)

Да в общем то никому не интересно есть ли в фоксе транзакции (это личное дело фокса)
Интересно обеспечивается ли ACID ???

нет конечно, почитайте хотя бы первую страницу этого топика
https://www.sql.ru/forum/actualthread.aspx?tid=619632&pg=1#6733065
3 фев 09, 13:09    [6772159]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
locky

Кто ломал фундамент? Где?

Не прикидывайтесь. Вы! Вы ломали его! :) (по-Ленински вытянув руку впИрёт, ткнув собеседника указательным пальцем)

locky
Или вы считаете, что расширение списка/состава атрибутов - есть "ломка фундамента"?

Коллега, Вы слыхали про процессы аналитического обследования бизнеса клиента? А про концептуальный этап? А про технические и рабочие проекты с инкапсулированными issue для девелоперов? А про спецификации к решениям?
Когда придет озарение - поговорим с Вами о "добавить" "недостающее" поле. После прохождения всех бюрократических этапов - добавить поле - раз плюнуть, перекомпилить сборку - раз плюнуть, выслать клиенту инструкцию по накату обновления и зарегистрировать билд - раз плюнуть. В чем же "соль" в Вашей "универсальности", поведайте мне?
Второе - а если Вы и еще парочка "сильных" девелоперов уволятся, умрут, исчезнут, телепортируются? Что делать? Кто будет рыть тонны Вашего недокументированного наколленного кода? Как это отразится на компании, в которой Вы работаете?

locky
Ну, не знаю, м.б. в случае ORM так и есть (ведь придётся, наверное, переделывать классы етк).

Добавить (не ручками, а тем же генератором кода - нажать кнопку "обновить DML") новый член в классе сущности ничуть не сложнее, чем Вы сделаете альтер тэйбл (и то даже Вы альтерить не будете, а воспользеутесь нормальным дизайнером (Management Studio))
Коллега, время коленочных забвений и тонны "неуправляемого" (недокументированного) кода уходить в небытие, как бы Вы этого не хотели. Уж простите, что приходится Вас разочаровывать :)

locky
Угу. Внесение изменения в базу - это "на коленке", "ручками".

Да смотрите же глубже - я говорю про сам процесс, а не про эти мелочи. Так я угадал про то, как поставлен у Вас процесс, Локи?

locky
А внесение изменения и в базу и в клиента/клиентские классы - это, оказывается, кошер, методология, не-бардак, в корне верно...
И, что самое главное - летает!

Ой, устаю я от Вас. Вам что в лоб, что по-лбу :) Хватит издеваться - и осознайте истину. Уверен, в душе Вы меня понимаете и поддерживаете, но, возможно, гордость не позволяет согласиться и принять "Истину современной жизни"

locky
Ессно, если по изменению структуры БД мне необходимо вносить изменения в еще тыщу разных мест на клиенте - то "всё не так просто", кто бы спорил.

Вот-вот... Да хватит про код - про документацию почему молчим? Или ее нету?

locky
Изолированно, друг мой, изолированно

Ладно, уговорили. Верю :)

locky
Нда. Гоняем данные из БД в CLR и обратно, чтобы в одном месте - выбрать, во втором - собрать, снова выгнать запрос, снова получить данные, обработать, результат вернуть... Такое методологие, наверное, и правда - нужно всецело документировать и т.д. - ибо можно будет и ноги и голову поломать, пытаясь потом разобраться....

Ну Вы опять "максимализируете". Я просто привёл пример, что можно. Это не значит, что на каждый пук нужно писать SQLCLR функционал. Более того, я даже противник такого подхода. Я убежден, что SQLCLR нужна там, где сиквельной стороной бизнес-блок не реализуется, либо реализуется, но через одно место. К примеру, работа с файловой системой, вебсервисами и т.д.
Помните, публиковал работу с AD. Ну не красота-ли? Там довольно мощные вещи можно ваять...
Например, выгрузка в xml смерженных xml (данные сосутся из таблиц). Посмотрите, какая красота:

[SqlProcedure]
public static void OutputXml(SqlXml XmlData, SqlString Filename)
{
    XmlDocument xmlDoc = new XmlDocument();

    try
    {
        xmlDoc.LoadXml(XmlData.Value);
        xmlDoc.Save(Filename.Value);
    }
    catch (Exception ex)
    {
        SqlContext.Pipe.Send(ex.Message);
    }
}

CREATE PROCEDURE OutputXml
      @XmlData xml,
      @FileName nvarchar(1024)
AS 
EXTERNAL NAME [CLRT].[CLRT.Class].[OutputXml]
GO

DECLARE @output xml
SET @output = (select
	CAST(		
		(SELECT * FROM AdventureWorks.Production.ProductPhoto FOR xml auto, elements)
		+
		(SELECT * FROM AdventureWorks.Sales.Currency AS Currency FOR xml auto, elements)			
	AS xml) for xml path(''), root('DataSet'))
	
EXEC OutputXml @output, 'C:\Output.xml'
GO
3 фев 09, 13:10    [6772167]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 28 29 30 31 32 [33] 34 35 36 37 .. 75   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить