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

Откуда:
Сообщений: 103
Tapac
проходящий.
Tapac
Из FoxPro тестируем поиск в dbf:
SET SAFETY OFF
SET TALK OFF

CLEAR ALL
USE C:\test.dbf
n = 100

s0 = SECONDS()
FOR i=1 TO n
	SELECT ID FROM test WHERE data = "test text" INTO CURSOR tmp
ENDFOR
s = SECONDS()

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

Из FoxPro тестируем поиск в Oracle:
[src]
SET SAFETY OFF
SET TALK OFF

n = 100
nh = SQLCONNECT( "test", "test", "test")
SQLPREPARE( nh, "SELECT ID FROM test WHERE data='test text'")

s0 = SECONDS()
FOR i=1 TO n
SQLEXEC(nh)
ENDFOR
s = SECONDS()

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


SQLEXEC() внутри цикла загружает результаты запроса "SELECT ID FROM test WHERE data='test text'", полученные Oracle, и через ODBC загружает в локальный курсор FoxPro с именем (по-умолчанию) Sqlresult.

Не знаю в FoxPro команд предварительного построения и сохранения планов запросов. Укажите -- поправим тест.

ЭЭээээ эйн момент дружок!
Что это за пример у тебя такой странный?
Зачем нам Foxpro сравнивать с Foxpro да ещё через драйвер ODBC Оракла?
И второе: Зачем там стоит цикл?
Ты хотел сравнить скорость выполнения команд интепретатором команд?
У нас тут спор о скорости самого SQL в Foxpro - т.е. скорости Rushmore внутри комманды SQL.
Скорость интерпретатора это уже второй вопрос.
3 фев 09, 05:22    [6769966]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

Откуда:
Сообщений: 103
Tapac

Итак, результаты поиска по таблицам с 1 млн.записей
Среднее время поиска в FoxPro: 0.00049
Среднее время поиска в Oracle: 0.00051

А теперь, наберемся терпения и проведем тот же тест на 100 млн.записей.
Среднее время поиска в FoxPro: 0.05579
Среднее время поиска в Oracle: 0.00053

Евгений, факты -- упрямая вещь.
Для чего я сделал этот тест? Только ...ради Вас.
Поставьте любую доступную серверную СУБД и проверьте сами.
Начать учиться никогда не поздно.

P.S. Хамить и ерничать мне бесполезно -- отвечу только знАчимую часть реплик.

Ну ты Тарасик и артист!
Ктож так проверяет?
Сейчас объясню где ты ошибся!
Во первых к слову скажу - в твоей программе Foxpro выдаёт ошибку в строке:
CREATE TABLE C:\test.dbf ( ID I, Data C(10)) && Я везде в программе убрал C:\
Vista в корень C:\ запрещает писать (по крайней мере у меня так) - будем считать этот момент не существенным, но ты больше так не делай Тарасик!
Теперь второй момент! Я объясню тебе в чём кроется твоя ошибка эксперемента!
Ты делаешь в цикле повторяющиеся команды.
Foxpro их абсолютно честно берёт и выполняет, каждый раз при этом подключая механизм Rushmore!
А что делает Оракл? Оракл анализирует повторяющиеся запросы и даёт готовый ответ! Оракл не будет 100 раз лазить в милионе записей если запрос SQL один и тот же и уже сохранился в кэшэ! Он просто на твой запрос выдаст готовый ответ - записи из кэша! Ёптыть ... Тарасик, а ты однако циркач...
Я немного изменил твою программу применительно к своей базе Фамилии из 195 милионов записей.
................................................................
SET SAFETY OFF
SET TALK OFF

CLEAR ALL
USE фамилии.dbf
n = 100

s0 = SECONDS()
FOR i=1 TO n
SELECT Фамилия FROM фамилии WHERE Фамилия = "test text" INTO CURSOR tmp
ENDFOR
s = SECONDS()

? 'Общее время выполнения:' + LTRIM(STR(s-s0,7,5))
? 'Среднее время поиска:' + LTRIM(STR((s-s0)/n,7,5))
................................................................
Общее время выполнения 100 запросов среди 195 милионов записей:14.3570 секунд.
А теперь измени программу! - заставь Оракл делать каждый раз новую операцию в цикле и он заткнётся!
Не надо вешать людям лапшу на уши что Оракл это сделает быстрее чем Rushmore!
3 фев 09, 07:13    [6770016]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Егоров Александр
Member

Откуда: Хабаровск
Сообщений: 517
Tapac

Итак, результаты поиска по таблицам с 1 млн.записей
Среднее время поиска в FoxPro: 0.00049
Среднее время поиска в Oracle: 0.00051

А теперь, наберемся терпения и проведем тот же тест на 100 млн.записей.
Среднее время поиска в FoxPro: 0.05579
Среднее время поиска в Oracle: 0.00053


Это локальный тест. А если между клиентом и базой\dbf-кой сетка?
3 фев 09, 08:15    [6770052]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
проходящий.
locky
СУБД, не имеющая стейтмента BEGIN TRAN - не имеет права на существование.

Просто кусочек хелпа:
Visual FoxPro 9.0 SP2  
BEGIN TRANSACTION Command
See Also Example

Begins a transaction.

Я вам щаз приведу кусочек из хелпа, в котором написано, что существуют вложенные транзакции.
И что - вы тут-же поверите, что вложенные транзакции таки существуют?
(автономные - не вспоминать, они нифига не вложенные).


В BDB несомненно (Oracle кстати)
3 фев 09, 08:20    [6770055]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Tapac
Member

Откуда: Альметьевск
Сообщений: 100
Eugenkru1
Что это за пример у тебя такой странный?
Зачем нам Foxpro сравнивать с Foxpro да ещё через драйвер ODBC Оракла?


Евгений,
1. чтобы работать с сервером БД нужен клиент. Хоть какой-то. Почему бы не FoxPro и не через ODBC (не забываем, что тест я писал для Вас)?
2. намеренно написал тест для Oracle на стороне клиента (а не на стороне сервера в PL/SQL), чтобы включить "накладные расходы" по доставке данных до клиента FoxPro и поставить в равные условия с тестом dbf.

Eugenkru1

И второе: Зачем там стоит цикл?
Ты хотел сравнить скорость выполнения команд интепретатором команд?
У нас тут спор о скорости самого SQL в Foxpro - т.е. скорости Rushmore внутри комманды SQL.
Скорость интерпретатора это уже второй вопрос.


Цикл стоит для того, чтобы усреднять время выборки в СУБД и передачи данных между клиентом и сервером, время исполнения самих операторов FOR ... и ENDFOR исчезающе мало, по крайней мере меньше 0.0000001
3 фев 09, 08:22    [6770058]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Fox5631
Tapac,
ты подтверждаешь то, что я написал несколько страниц назад. Ты не читал весь топик.


Что в Oracle враги встроили рашмор ???
3 фев 09, 08:22    [6770059]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
Или, как обычно - "в оракле ЭТОГО нет - значит, ЭТО - ненужно!"? ;)
И, если это можно сделать "штатными средствами" (желательно в том виде, в котором я представил, т.е. без дополнительных параметров, процедур-обвязок етк) - было бы интересно посмотреть.


Скорее как обычно "шашечки или ехать". В Oracle begin/end не имеет отношения к управлению транзкциями (и IMHO это правильно). Так что в нужных местах ставьте commit.
3 фев 09, 08:34    [6770077]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky
мне интересно - как поступают люди, "изначально писавшие на оракле". Т.е. - "как там принято поступать".


Как один из вариантов, делаются процедуры-обвязки, вызывающие commit (или rollback если прилетело исключение). Остальные процедуры транзакций не фиксируют. Приложение вызывает процедуры-обвязки. Поскольку имеются пакеты, создание дополнительных процедур не является проблемой.

Повторю, это ОДИН ИЗ возможных вариантов
3 фев 09, 08:47    [6770114]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Tapac
Member

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

Итак, результаты поиска по таблицам с 1 млн.записей
Среднее время поиска в FoxPro: 0.00049
Среднее время поиска в Oracle: 0.00051

А теперь, наберемся терпения и проведем тот же тест на 100 млн.записей.
Среднее время поиска в FoxPro: 0.05579
Среднее время поиска в Oracle: 0.00053

Евгений, факты -- упрямая вещь.
Для чего я сделал этот тест? Только ...ради Вас.
Поставьте любую доступную серверную СУБД и проверьте сами.
Начать учиться никогда не поздно.

P.S. Хамить и ерничать мне бесполезно -- отвечу только знАчимую часть реплик.


...

Ктож так проверяет?
Сейчас объясню где ты ошибся!
Во первых к слову скажу - в твоей программе Foxpro выдаёт ошибку в строке:
CREATE TABLE C:\test.dbf ( ID I, Data C(10)) && Я везде в программе убрал C:\
Vista в корень C:\ запрещает писать (по крайней мере у меня так) - будем считать этот момент не существенным, но ты больше так не делай ...!


Будем считать несущественным, что моя учетная запись в ОС на собственном буке всегда входит в группу локальных админов, поэтому я всегда (в прошлом программер и админ) могу себе позволить писать в C:\.

Eugenkru1

Теперь второй момент! Я объясню тебе в чём кроется твоя ошибка эксперемента!
Ты делаешь в цикле повторяющиеся команды.
Foxpro их абсолютно честно берёт и выполняет, каждый раз при этом подключая механизм Rushmore!
А что делает Оракл? Оракл анализирует повторяющиеся запросы и даёт готовый ответ! Оракл не будет 100 раз лазить в милионе записей если запрос SQL один и тот же и уже сохранился в кэшэ! Он просто на твой запрос выдаст готовый ответ - записи из кэша! ... ... ..., а ты однако ... ...
Я немного изменил твою программу применительно к своей базе Фамилии из 195 милионов записей.
................................................................
SET SAFETY OFF
SET TALK OFF

CLEAR ALL
USE фамилии.dbf
n = 100

s0 = SECONDS()
FOR i=1 TO n
SELECT Фамилия FROM фамилии WHERE Фамилия = "test text" INTO CURSOR tmp
ENDFOR
s = SECONDS()

? 'Общее время выполнения:' + LTRIM(STR(s-s0,7,5))
? 'Среднее время поиска:' + LTRIM(STR((s-s0)/n,7,5))
................................................................
Общее время выполнения 100 запросов среди 195 милионов записей:14.3570 секунд.
А теперь измени программу! - заставь Оракл делать каждый раз новую операцию в цикле и он заткнётся!
Не надо вешать людям лапшу на уши что Оракл это сделает быстрее чем Rushmore!


Согласен, что кэширование Oracle'ом плана запросов и результатов запросов в приведенном тесте присутствует.
Изменим тест таким образом, чтобы заставить 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='test text'" + REPLICATE('-', n))
ENDFOR
s = SECONDS()

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

Результат: 0.0010400

Итак, напоминаю:

Тест на 100 млн.записей.
Среднее время поиска в FoxPro: 0.05579
Среднее время поиска в Oracle (с кэшированием): 0.00053
Среднее время поиска в Oracle (без кэширования): 0.00104
3 фев 09, 08:48    [6770118]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
Tapac,

ясное дело, оракл у рашмора секрентную патентованую технологию украл, а так технология секретная, никто оракла поймать за руку не может
3 фев 09, 08:52    [6770132]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
softwarer
Нормальных прикладных задач, где без LTT приходится извращаться, я пожалуй сходу даже и не вспомню.


Ну как-же ? А набившее оскомину формирование ПРОИЗВОЛЬНЫХ отчетов, требующее каждый раз НОВОЙ структуры временной таблицы ???
3 фев 09, 08:53    [6770136]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Eugenkru1
Оракл не будет 100 раз лазить в милионе записей если запрос SQL один и тот же и уже сохранился в кэшэ! Он просто на твой запрос выдаст готовый ответ - записи из кэша!


Аааа держите меня семеро !!! Оно СЛЫШАЛО про library cache
Только слышало звон, не надо путать кэш разобранных ЗАПРОСОВ с кэшем ДАННЫХ.
Разобранный запрос это ПЛАН, по которому Oracle получает НОВЫЕ данные (с диска или из кэша другая тема).

Про висту и корень Це улыбнуло.

Евгений, общественность с нетерпением ждет ВАШЕГО варианта тестирования (честного, а не как у Тараса ;)
3 фев 09, 09:12    [6770199]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
Gluk (Kazan)

Ну как-же ? А набившее оскомину формирование ПРОИЗВОЛЬНЫХ отчетов, требующее каждый раз НОВОЙ структуры временной таблицы ???

Рашмор разве не решает эту задачу ?
3 фев 09, 09:30    [6770294]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Изопропил
Gluk (Kazan)

Ну как-же ? А набившее оскомину формирование ПРОИЗВОЛЬНЫХ отчетов, требующее каждый раз НОВОЙ структуры временной таблицы ???

Рашмор разве не решает эту задачу ?
]

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

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

Итак, результаты поиска по таблицам с 1 млн.записей
Среднее время поиска в FoxPro: 0.00049
Среднее время поиска в Oracle: 0.00051

А теперь, наберемся терпения и проведем тот же тест на 100 млн.записей.
Среднее время поиска в FoxPro: 0.05579
Среднее время поиска в Oracle: 0.00053


Это локальный тест. А если между клиентом и базой\dbf-кой сетка?


Сетевой вариант. В качестве файла-сервера и сервера Oracle выступает тот же Sony Vaio VGN-AR41SR с той же самой инстанцией Oracle и dbf с 100 млн.записей. Сеть: 54 Мбит/c (wi-fi соединение)

Среднее время поиска в FoxPro: 0.07071
Среднее время поиска в Oracle ("с кешем"): 0.00262
Среднее время поиска в Oracle ("без кеша"): 0.00332
3 фев 09, 09:55    [6770437]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
locky
Это когда "очень удобно реализовывать обработку данных на стороне клиента/промежуточного звена"?

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

locky
И, позвольте мне спросить - накуя я должен хранить данные отдельно, а обрабатывать их - отдельно?

Вы так или иначе на клиенте всё-равно их "обрабатываете".

locky
М.б. лучше сразу к фоксу возвернутся?

Да простите, занесло меня в другую степь.

locky
Любой промслой, любая допбиблиотека, "маппинг" БД на что угодно - это "Тормоз++".

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

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


Локи, RTFM. Когда придет озарение - тогда и поговорим. На эту тему уже много дров перерублено.

http://ru.wikipedia.org/wiki/ORM
3 фев 09, 10:08    [6770536]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

Откуда:
Сообщений: 103
Tapac,
Посмотри строчку:
SQLEXEC(nh, "SELECT ID FROM test WHERE data='test text'" + REPLICATE('-', n))
мне абсолютно не нравится надпись: data='test text' + REPLICATE('-', n)
У тебя поле к примеру ограниченно 10 знаков и твои минусы в хвосте отрубятся не доходя до этапа кэширования и как сработает SQL оракла мы не знаем.
Не мог бы ты как админ примерчик по убедительнее изобресть?
3 фев 09, 10:22    [6770655]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Sergey Orlov
Member

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

ребята, а мне честно говоря пофиг ваши измерения скорости, мне в SQL-варианте важны другие составляющие, например, чтобы базу никто не спер, ну и другие. И абсалютно пофиг за сколько отобразятся данные у клиента, за 0.005 секунд или же за 0.5 сек, в современных компах это все зависит от самого компьютера и опеерационной системы, т.е. время необходимое для отображения данных превосходит время выборки. Кроме этого криво написанное приложение способно убить оба варианта..
3 фев 09, 10:38    [6770778]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

Откуда:
Сообщений: 103
Tapac,

придумай такой пример который меняет сам запрос а не только значение в цикле.
Значение можно написать даже data=SYS(2015) но сам запрос остаётся неизменным и оракл будет по любому использовать кэширование - это очевидно. Я не верю что фокс выигравший у оракла на 1 милионе записей будет проигрывать на 100 милионах. На мой взгляд тут дело просто в кэшировании повторяющихся запросов в твоём примере.
3 фев 09, 10:43    [6770802]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Eugenkru1
Tapac,
придумай такой пример который меняет сам запрос а не только значение в цикле.


А что мешает придумать пример в Fox-е кэширующий разобранный SQL-запрос ???
3 фев 09, 10:48    [6770840]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Eugenkru1
Member [заблокирован]

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

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

Вот именно! Абсолютно точно подмечено. Разница в скорости крошечная даже если она и есть! Зато Visual Foxpro универсален и пригоден для широченного круга задач! Огромный набор команд и функций делает его гибким и мощным. По поводу того чтоб никто не спёр тоже интересная тема и на фоксе она тоже решается легко!
3 фев 09, 10:51    [6770868]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
Сахават Юсифов
Member

Откуда: Орел
Сообщений: 3992
МСУ
Прежде чем так говорить, нужно хотя бы одну из перечисленных ORM пощупать, погонять профайлером генерируемый ORM запросы к серверу, а потом что-то утверждать. Вы - не правы.
Вы велосипеды изобретаете с каждой новой задачей - а я использую универсальную объектную модель, проекция структуры находится на вызывающей стороне.


Попробуй ка загони в ОРМ.

К сообщению приложен файл. Размер - 0Kb
3 фев 09, 10:55    [6770914]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
softwarer
Не так ли, конечно.

А, так оракл уже научился не делать автокоммит до и после DDL?
Видимо, в это время я был в отпуске.

softwarer

Вот как раз внутри процедуры такому объявлению делать совершенно нечего. Процедура - это место для описания логики. Объявления раздувают её и усложняют восприятие.

Можно еще все переменные вынести из процедуры в пакет (пакет по такому случаю завести, если еще нету). Нефиг переменным засорять и раздувать, не так ли?

softwarer

В общем, примера пользы LTT так и не приведено, только пара лозунгов

Пример пользы локальных временных таблиц - хранение промежуточных результатов. Собственно, трудно себе представить - для чего нужны таблицы (кроме как для хранения данных) и, особенно, временные (кроме как что-то недолго похранить).
3 фев 09, 10:55    [6770926]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

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

Про этот вариант я знаю (он мне не сильно нравится)
Если существуют еще кошерные варианты/методы - делитесь. Не глума ради - и просто интересно, и пригодится, наверное.
3 фев 09, 11:00    [6770975]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД!  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
МСУ
Вы так или иначе на клиенте всё-равно их "обрабатываете".

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


МСУ
Вы велосипеды изобретаете с каждой новой задачей - а я использую универсальную объектную модель, проекция структуры находится на вызывающей стороне.

С чего вы взяли про велосипеды?
Это, простите, у вас, насколько я понимаю, при изменении структуры данных заодно меняется и структура классов. У меня всё банальнее - об изменении структуры данных клиент вообще не знает (да ему и плевать глубоко на то, что делается на стороне сервера).
Да и самой серверной стороне - тоже глубоко плевать на изменение структуры данных.
И всё это по строгим канонам без всяких излишеств. Реюзабельно. Сопровождаемо. Изолировано.

МСУ

Локи, RTFM. Когда придет озарение - тогда и поговорим. На эту тему уже много дров перерублено.
http://ru.wikipedia.org/wiki/ORM

Сто раз скажи "халва" - а во рту слаще не станет.
Если дров много перерублено - значит, не всё там однозначно. И значит, моя т.з. - является достаточно обоснованной и распространённой.

зы а за озарением я пойду к Свидетелям Иеговы
3 фев 09, 11:06    [6771030]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 27 28 29 30 31 [32] 33 34 35 36 .. 75   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить