Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
 Re: Мелкомягкий кошмар  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
qwerty112
а вот, например, JetSQL-ный PIVOT (TRANSFORM) по неизвестному к-ву столбцов, не поддерживает ни одна "взрослая" СУБД, почему-то ...


+1. Печально, но факт!
25 июл 13, 22:24    [14618886]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
Galadriel75
Member

Откуда:
Сообщений: 1388
PaulWist
Galadriel75
.. .. я перепробовал столько сред разработки, столько платформ.... ни одна из них меня не вынуждала выливать потоки страшной энергии в чистый, легкоусваиваемый, доходчивый и кошмарный мат! а вот аксесс и вижуалфокспро - это сделать смогли... поэтому я решил их отправить в разряд выкидышей, с которыми более нет интереса связываться!


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


неудобный и глючный
долго рассказывать, нет желания и времени... если какую-то мелочь - то можно побыстрому сделать, если что-нибудь повесомее -вот тогда вся хрень и повылазит постепенно.
29 июл 13, 00:45    [14629899]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
mad_nazgul
Member

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


Они такие. ;-)
Только Access особо не предназначен для "тяжелой" разработки.
А у FoxPro "хвосты" еще с 80-х годов прошлого века тянутся.
Это не значит, что они плохие.
Просто, так скажем, довольно специфичный продукт. :-)
29 июл 13, 08:07    [14630152]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
qwerty112
Guest
Galadriel75
PaulWist
пропущено...


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


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

сэр, я охреневаю с уровня ваших аргументов !
29 июл 13, 15:25    [14632582]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
Galadriel75
Member

Откуда:
Сообщений: 1388
qwerty112
Galadriel75
пропущено...


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

сэр, я охреневаю с уровня ваших аргументов !


ничего личного, только факты!
31 июл 13, 21:05    [14645273]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
Galadriel75
ничего личного, только факты!


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

Факты про Access
Из всех "настольных" СУБД - выжил только Access.
Остальные не выдержали конкуренции.
1 авг 13, 07:18    [14646326]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
Galadriel75
Member

Откуда:
Сообщений: 1388
mad_nazgul
Galadriel75
ничего личного, только факты!


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

Факты про Access
Из всех "настольных" СУБД - выжил только Access.
Остальные не выдержали конкуренции.


я знаю, что такое FoxPrо Я целые комплексы делал на FoxPro for DOS - к нему нет претензий
я забил только на VisualFoxPro

По поводу личного мнения - я работал в том числе и с Access и знаю, что он глюковатый и никто меня не сможет убедить в том, что черное - на самом деле белое...
1 авг 13, 11:19    [14647322]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5825
Galadriel75
я знаю, что такое FoxPrо Я целые комплексы делал на FoxPro for DOS - к нему нет претензий
я забил только на VisualFoxPro


В Visual FoxPro можно работать точно так же как и в FoxPro for DOS. ;-)
Даже формочки переносятся один к одному.

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


Я бы не сказал что он такой уж глюкавый...
Просто не стоит от него ожидать, что он будет работать как MS SQL :-)
1 авг 13, 13:28    [14648302]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
qwerty112
FreemanZAV
Реализация SQL в Access хреновая, что сводит на нет все его удобства.

даа, ващето - и "похужее видали" ...

а вот, например, JetSQL-ный PIVOT (TRANSFORM) по неизвестному к-ву столбцов, не поддерживает ни одна "взрослая" СУБД, почему-то ...


Скорее всего PIVOT нет в ANSI SQL. А вот то, что в Access нельзя сделать даже элементарные стандартные join-ы:

1
2

это удручает.

Я не говорю уже об аналатических функциях, CTE, рекурсивных запросах и т.п.

P.S. базируюсь на знаниях Access 2003. Возможно сейчас ситуация исправилась
5 авг 13, 16:58    [14665294]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
pkarklin
qwerty112
а вот, например, JetSQL-ный PIVOT (TRANSFORM) по неизвестному к-ву столбцов, не поддерживает ни одна "взрослая" СУБД, почему-то ...


+1. Печально, но факт!


Не совсем факт. Собственно пример для oracle:

select  *
  from  (
         select  job,
                 deptno,
                 sal
           from  emp
        ) pivot xml(sum(sal) for job in (select distinct job from emp))
5 авг 13, 17:07    [14665338]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
FreemanZAV,

автор
Собственно пример для oracle


И что он дает на выходе? Если xml, то некломильфо...
5 авг 13, 18:10    [14665760]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
pkarklin
FreemanZAV,

автор
Собственно пример для oracle


И что он дает на выходе? Если xml, то некломильфо...


А чем плох xml?
5 авг 13, 19:31    [14666179]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
FreemanZAV
А чем плох xml?


Ничем не плох. Просто для его обоработки на клиенте нужны дополнительные телодвижения, чем если бы это был "обычный" рекордсет.
5 авг 13, 19:50    [14666220]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
qwerty112
Guest
FreemanZAV
А вот то, что в Access нельзя сделать даже элементарные стандартные join-ы:

1
2

это удручает.

можно ! :)

1.
SELECT *
FROM PB_T_GENLGM LEFT JOIN PB_T_GL_OPENING_BALANCE 
ON (PB_T_GENLGM.numGlCode = PB_T_GL_OPENING_BALANCE.numGlCode 
And (PB_T_GL_OPENING_BALANCE.numYear=2006 Or PB_T_GL_OPENING_BALANCE.numYear is null) )


п.2 - так ваще есть в Аксовском ФАКе
https://www.sql.ru/faq/faq_topic.aspx?fid=213 Q26

FreemanZAV
Я не говорю уже об аналатических функциях, CTE, рекурсивных запросах и т.п.

рекурсии - много где нет (МуСКЛ - мощнейшая СУБД ! а рекурсии - нет. Что же тут тогда можно "маленькому" Акцессу предъявлять ? :)) )

CTE - да, удобно, наглядно и всё такое, но это, всё же, как была "дериверид тэйбл" - так и осталась "дериверид тэйбл", которые в Аксе использовать можно

аналитические функции - опять же в МуСКЛ - нету ! в МС СКЛ до 2005 - не было, - как-то справлялись, же...
всякие ROW_NUMBER / RANK / DENSE_RANK, тем более, вполне можно "слепить" из корр.подзапроса
А в Акс-е (если говорить об Акс-е, а не об Jet-SQL) помимо этого, можно сделать вообще практически всё - функцию на ВБА написать соотв., и использовать в запросе ...

FreemanZAV
P.S. базируюсь на знаниях Access 2003. Возможно сейчас ситуация исправилась

даа, я тоже "на знаниях Access 2003",
но могу сказать, что в послед.версиях - ничего не улучшилось (скорее наоборот)
вот это, действительно удручает ...
МС, откровенно, Акс "гробит" - это факт
5 авг 13, 21:20    [14666509]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
qwerty112
можно ! :)



В моем посте ключевое слово "стандартные" (я говорю об ANSI стандарте). Стандартные сделать нельзя - нужно расставлять кучу скобок. Об этом и говориться в ссылках.


qwerty112
рекурсии - много где нет (МуСКЛ - мощнейшая СУБД ! а рекурсии - нет. Что же тут тогда можно "маленькому" Акцессу предъявлять ? :)) )

Я не предъявляю, я говорю, что нет. Да и причём здесь МуСКЛ ? Речь вроде об Access?


qwerty112
CTE - да, удобно, наглядно и всё такое, но это, всё же, как была "дериверид тэйбл" - так и осталась "дериверид тэйбл", которые в Аксе использовать можно

Не совсем. Гуглим про оператор with


qwerty112
аналитические функции - опять же в МуСКЛ - нету ! в МС СКЛ до 2005 - не было, - как-то справлялись, же...



Опять же, причём здесь МуСКЛ ?



qwerty112
всякие ROW_NUMBER / RANK / DENSE_RANK, тем более, вполне можно "слепить" из корр.подзапроса

На этом список аналитических функций не заканчивается. "слепить" можно, но далеко не всё.

qwerty112
А в Акс-е (если говорить об Акс-е, а не об Jet-SQL) помимо этого, можно сделать вообще практически всё - функцию на ВБА написать соотв., и использовать в запросе ...

ВБА там тоже убогий. Наcколько я помню, в нем нет даже наследования. А то, что на нём можно написать аналитическую функцию, ну или хотя бы агрегатную, я сильно сомневаюсь.
6 авг 13, 08:16    [14667258]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
pkarklin
FreemanZAV
А чем плох xml?


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


Это смотря что за клиент
6 авг 13, 08:23    [14667271]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
qwerty112
Guest
FreemanZAV
qwerty112
CTE - да, удобно, наглядно и всё такое, но это, всё же, как была "дериверид тэйбл" - так и осталась "дериверид тэйбл", которые в Аксе использовать можно

Не совсем. Гуглим про оператор with

что "не совсем" ?
WITH обобщенное_табличное_выражение (Transact-SQL)
Задается временно именованный результирующий набор, называемый обобщенным табличным выражением (ОТВ).
...

предложите запрос с CTE, который нельзя переписать через "дериверид тэйбл" (без рекурсии, разумеется) и тогда поговорим ...
6 авг 13, 10:28    [14667822]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
qwerty112
FreemanZAV
пропущено...

Не совсем. Гуглим про оператор with

что "не совсем" ?
WITH обобщенное_табличное_выражение (Transact-SQL)
Задается временно именованный результирующий набор, называемый обобщенным табличным выражением (ОТВ).
...

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



Что нибудь типа такого:

WITH Inc_Out(m_sum, type, date, point) AS (
  SELECT inc, 'inc' type, date, point
  FROM Income
  UNION ALL
  SELECT inc, 'inc' type, date, point
  FROM Income_o
  UNION ALL
  SELECT out, 'out' type, date, point
  FROM Outcome_o
  UNION ALL
  SELECT out, 'out' type,date, point FROM Outcome )
SELECT 'max' min_max,* FROM Inc_Out
WHERE m_sum >= ALL( SELECT m_sum FROM Inc_Out)
UNION ALL
SELECT 'min', * FROM Inc_Out
WHERE m_sum <= ALL( SELECT m_sum FROM Inc_Out)
6 авг 13, 11:52    [14668388]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
qwerty112
Guest
FreemanZAV
qwerty112
пропущено...

что "не совсем" ?
пропущено...

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



Что нибудь типа такого:

WITH Inc_Out(m_sum, type, date, point) AS (
  SELECT inc, 'inc' type, date, point
  FROM Income
  UNION ALL
  SELECT inc, 'inc' type, date, point
  FROM Income_o
  UNION ALL
  SELECT out, 'out' type, date, point
  FROM Outcome_o
  UNION ALL
  SELECT out, 'out' type,date, point FROM Outcome )
SELECT 'max' min_max,* FROM Inc_Out
WHERE m_sum >= ALL( SELECT m_sum FROM Inc_Out)
UNION ALL
SELECT 'min', * FROM Inc_Out
WHERE m_sum <= ALL( SELECT m_sum FROM Inc_Out)

нуу, так
SELECT 'max' min_max,* FROM 
	( SELECT inc m_sum, 'inc' type, date, point FROM Income
	  UNION ALL
	  SELECT inc, 'inc' type, date, point FROM Income_o
	  UNION ALL
	  SELECT out, 'out' type, date, point FROM Outcome_o
	  UNION ALL
	  SELECT out, 'out' type,date, point FROM Outcome ) Inc_Out

WHERE m_sum >= 
		ALL( SELECT m_sum FROM 
				( SELECT inc m_sum, 'inc' type, date, point FROM Income
				  UNION ALL
				  SELECT inc, 'inc' type, date, point FROM Income_o
				  UNION ALL
				  SELECT out, 'out' type, date, point FROM Outcome_o
				  UNION ALL
				  SELECT out, 'out' type,date, point FROM Outcome )Inc_Out)

UNION ALL

SELECT 'min', * FROM 
	( SELECT inc m_sum, 'inc' type, date, point FROM Income
	  UNION ALL
	  SELECT inc, 'inc' type, date, point FROM Income_o
	  UNION ALL
	  SELECT out, 'out' type, date, point FROM Outcome_o
	  UNION ALL
	  SELECT out, 'out' type,date, point FROM Outcome ) Inc_Out
WHERE m_sum <= 
		ALL( SELECT m_sum FROM 
				( SELECT inc m_sum, 'inc' type, date, point FROM Income
				  UNION ALL
				  SELECT inc, 'inc' type, date, point FROM Income_o
				  UNION ALL
				  SELECT out, 'out' type, date, point FROM Outcome_o
				  UNION ALL
				  SELECT out, 'out' type,date, point FROM Outcome )Inc_Out)

и ?
6 авг 13, 12:13    [14668537]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

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

Незачёт. Выборки из таблиц повторяются. В результате получаем жуткую потерю производительности и жуткий синтаксис
6 авг 13, 13:10    [14669062]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
qwerty112
Guest
FreemanZAV
жуткий синтаксис

про синтаксис - я и говорил
qwerty112
CTE - да, удобно, наглядно и всё такое, но это, всё же, как была "дериверид тэйбл" - так и осталась "дериверид тэйбл", которые в Аксе использовать можно

FreemanZAV
В результате получаем жуткую потерю производительности

(и чо я не удивляюсь такому ответу ... :) )
и что, правда ?
и вы готовы, планами запросов это доказать ?
или это "высер" такая же "профессиональная точка зрения", как и про джойны в Акцессе ?
6 авг 13, 13:34    [14669275]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
qwerty112
Guest
даа, и кстати
FreemanZAV
qwerty112
предложите запрос с CTE, который нельзя переписать через "дериверид тэйбл" (без рекурсии, разумеется) и тогда поговорим ...

Что нибудь типа такого:
....

даже если бы и была бы "жуткая потеря производительности" (а её - не будет, поверь дяде),
задачку-то, вы не выполнили ... :)
6 авг 13, 13:40    [14669337]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
qwerty112
про синтаксис - я и говорил

Я и не спорил

qwerty112
или это "высер"

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

qwerty112
и вы готовы, планами запросов это доказать ?

Кстати планы в Акцессе получить не так-то просто - ещё один минус. Может Acсess умеет материализовать такие запросы (хотя меня берут сомнения) - тогда в в части производительности я не прав. Но опять же - менее убогим Acess-овский SQL не становится.

qwerty112
"профессиональная точка зрения", как и про джойны в Акцессе ?


Моя точка зрения как раз и подтвердилась в Акцессовском faq
Вместо простого
select * from A left join B on A.A=B.B left join C on A.A=C.C

В Аксессе надо в таких запросах ставить скобки:
select * from ((((A left join B on A.A=B.B) left join C on A.A=C.C) left join D on A.A=D.D) left join E on A.A=E.E) left join F on A.A=F.F


В итоги три join вместо двух. Мне этот синтаксис кажется несколько бредовым
6 авг 13, 14:06    [14669526]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
FreemanZAV

В итоги три join вместо двух. Мне этот синтаксис кажется несколько бредовым


Насчёт 3-х join не прав, но синтаксис всё равно бредовый
6 авг 13, 14:19    [14669622]     Ответить | Цитировать Сообщить модератору
 Re: Мелкомягкий кошмар  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
qwerty112
даже если бы и была бы "жуткая потеря производительности" (а её - не будет, поверь дяде)

Не верю.

qwerty112
задачку-то, вы не выполнили ... :)


Если акцесс в derived tables будет выполнять повторные чтения таблиц, то задачу я выполнил.
6 авг 13, 14:47    [14669809]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить