Здравствуйте, alex_public, Вы писали:

_>Как будет выглядеть решение на SQL или Linq? )
В этой задаче необходимо создавать новые данные, а это, как я уже писал, не совсем задача сиквела, его задача — манипулировать существующими. Тем не менее, можно извернуться и на SQL пользуясь особенностями конкретной реализации. Например, так:

SELECT ROW_NUMBER() OVER(ORDER BY name) as id, STRING_SPLIT(REPLICATE(name + ', ', count), ', ') name FROM table

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

SELECT t1.id, t2.name FROM number t1 JOIN table t2 ON t1.id BETWEEN 1 AND t2.count

На линке должно быть еще проще, там есть средства генерации данных, join такой же.

_>Гугл использует BigTable, от которой собственно и зародилось "движение" NoSQL.
Ну а до BigTable они активно гоняли MySQL. Причем, что гугл, что яндекс — не лучший пример в данной дискуссии, так как задачи у них (мы же про поиск?) сильно отличаются от того, для чего предназначался SQL.
Там поиск нужен полнотекстовый, почти нет джойнов и всем крымский мост положить на целостность данных.

_>Что-то ты сам себе противоречишь. Твоя же цитата: " В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS".
У нас похоже опять проблемы, с тем кто и что написал. )) Мысль была в том, что не смотря на то, что язык получился кривой, теория на которой он таки базировался, все равно появилась раньше и позволила формально доказать, что кроме этого языка никакого доступа к внутренностям не надо. Иными словами, из того, что язык вышел неудачным, вовсе не следует, что его делали не имея никакой теоретической базы.

Здравствуйте, alex_public, Вы писали:

_>Как будет выглядеть решение на SQL или Linq? )
В этой задаче необходимо создавать новые данные, а это, как я уже писал, не совсем задача сиквела, его задача — манипулировать существующими. Тем не менее, можно извернуться и на SQL пользуясь особенностями конкретной реализации. Например, так:

SELECT ROW_NUMBER() OVER(ORDER BY name) as id, STRING_SPLIT(REPLICATE(name + ', ', count), ', ') name FROM table

Не, так не правильно, забыл, что STRING_SPLIT табличная функция, а не строковая, правильно так (но сути это не меняет):

SELECT ROW_NUMBER() OVER(ORDER BY [value]) id, [value] [name] FROM table OUTER APPLY string_split(RTRIM(REPLICATE([name] + ' ', [count])), ' ')

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

SELECT t1.id, t2.name FROM number t1 JOIN table t2 ON t1.id BETWEEN 1 AND t2.count

На линке должно быть еще проще, там есть средства генерации данных, join такой же.

_>Гугл использует BigTable, от которой собственно и зародилось "движение" NoSQL.
Ну а до BigTable они активно гоняли MySQL. Причем, что гугл, что яндекс — не лучший пример в данной дискуссии, так как задачи у них (мы же про поиск?) сильно отличаются от того, для чего предназначался SQL.
Там поиск нужен полнотекстовый, почти нет джойнов и всем крымский мост положить на целостность данных.

_>Что-то ты сам себе противоречишь. Твоя же цитата: " В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS".
У нас похоже опять проблемы, с тем кто и что написал. )) Мысль была в том, что не смотря на то, что язык получился кривой, теория на которой он таки базировался, все равно появилась раньше и позволила формально доказать, что кроме этого языка никакого доступа к внутренностям не надо. Иными словами, из того, что язык вышел неудачным, вовсе не следует, что его делали не имея никакой теоретической базы.