[БД] таблица с настройками - как лучше устроить
второе - конечно, т.к. не требуется пересоздание таблиц - при изменение кол-ва настроек.
Не уверен, что это такой уж большой плюс 
если проект делается по принципу "трех З" - зделал/заучил, здал, забыл, то да - это не плюс.
Если же требуется длительно "жить" с таким проектом, то это офигительный плюс.
Если же требуется длительно "жить" с таким проектом, то это офигительный плюс.
(существующих в единственном экземпляре)тогда в общем то пофиг как
второе - конечно, т.к. не требуется пересоздание таблиц - при изменение кол-ва настроек.почему пересоздание? есть ALTER TABLE ADD COLUMN
Если не правильно укажешь имя столбца,
SELECT MAX_USERS
FROM TABLE1
то ругнется СУБД, а в случае 2 не ругнется
Преобразовывать значение в строку и обратно тоже минус (можно конечно для каждого типа завести свой столбик .....).
на самом деле это только кажется, что первый вариант легче в сопровождении, если правильно программировать, то у второго варианта плюсов не остается
если проект делается по принципу "трех З" - зделал/заучил, здал, забыл, то да - это не плюс.
Если же требуется длительно "жить" с таким проектом, то это офигительный плюс.
1-й вариант намного лучше, потому что он более безопасен, в плане допущения случайных ошибок, во время разработки например
Если хранить пять - шесть общих параметров системы, то можно и в строчку.
В случае когда кол-во таких параметров переваливает за 50 и все разом они не нужны,
то удобней, мне кажется, использовать второй вариант.
И запросом доставать именно тот набор параметров, который нужен, а не все сразу.
В случае когда кол-во таких параметров переваливает за 50 и все разом они не нужны,
то удобней, мне кажется, использовать второй вариант.
И запросом доставать именно тот набор параметров, который нужен, а не все сразу.
вообще-то запросом можно выбрать и нужное мн-во колонок
Можно конечно...
Тогда, в моем понимании, вопрос сводится к тому, что удобней: каждый раз делать alter table или просто добавлять новую запись в таблицу.
Слишком широкие таблицы - это редко когда плюс.
Тогда, в моем понимании, вопрос сводится к тому, что удобней: каждый раз делать alter table или просто добавлять новую запись в таблицу.
Слишком широкие таблицы - это редко когда плюс.
писец!
и еще обсуждают же!
и еще обсуждают же!
Слишком широкие таблицы - это редко когда плюс.сами по себе широкие таблицы не являются ни минусом, ни плюсом, всё дело в том, как с ними работать
> почему пересоздание? есть ALTER TABLE ADD COLUMN
это и есть пересоздание.
если делать широкую таблицу, то :
1. не получиться использовать - БД как просто хранилище.
2. использовать распределенную (плагинную) архитектуру.
это и есть пересоздание.
если делать широкую таблицу, то :
1. не получиться использовать - БД как просто хранилище.
2. использовать распределенную (плагинную) архитектуру.
1. не получиться использовать - БД как просто хранилище.а зачем использовать БД как просто хранилище?
можно об этом по-конкретнее?
2. использовать распределенную (плагинную) архитектуру.
это и есть пересоздание.дело только в терминологии?
Я тоже за первый способ.
Если его чуток подправить, то можно иметь несколько наборов этих "параметров в единственном экземпляре", скажем testing/production или еще что-то.
Ну и те преимущества, о которых уже говорили: СУБД будет следить за типизацией, за опечатками в имени...
А бояться таблиц из одной записи странно, пользуются же в ООП синглтонами, никто не жалуется.
Если его чуток подправить, то можно иметь несколько наборов этих "параметров в единственном экземпляре", скажем testing/production или еще что-то.
Ну и те преимущества, о которых уже говорили: СУБД будет следить за типизацией, за опечатками в имени...
А бояться таблиц из одной записи странно, пользуются же в ООП синглтонами, никто не жалуется.
> зачем использовать БД как просто хранилище?
иначе, если делается трехзвенка, то получиться, что изменения/логику придется делать, как на сервере, так и в базе
также очень сильно усложняется повторное развертывание, т.е. допустим у клиента уже стоит версия - одно дело заменить только сервер, другое дело заменить сервер + корректно накатить изменения базы.
>> использовать распределенную (плагинную) архитектуру.
> можно об этом по-конкретнее
допустим мы делаем систему для многих клиентов (с разными потребностями тогда удобнее делать плагинную архитектуру, когда отдельные модули по минимуму знают друг о друге.
при такой архитектуре - мы под каждого клиента легко может собрать конфигурацию в виде необходимого набора модулей/плагинов.
все тоже самое, справедливо и для большой системы с одной установкой - т.к. опять же на этапе разработки мы еще не уверены, какие модули/плагины будут установлены при следующем релизе.
иначе, если делается трехзвенка, то получиться, что изменения/логику придется делать, как на сервере, так и в базе
также очень сильно усложняется повторное развертывание, т.е. допустим у клиента уже стоит версия - одно дело заменить только сервер, другое дело заменить сервер + корректно накатить изменения базы.
>> использовать распределенную (плагинную) архитектуру.
> можно об этом по-конкретнее
допустим мы делаем систему для многих клиентов (с разными потребностями тогда удобнее делать плагинную архитектуру, когда отдельные модули по минимуму знают друг о друге.
при такой архитектуре - мы под каждого клиента легко может собрать конфигурацию в виде необходимого набора модулей/плагинов.
все тоже самое, справедливо и для большой системы с одной установкой - т.к. опять же на этапе разработки мы еще не уверены, какие модули/плагины будут установлены при следующем релизе.
> дело только в терминологии?
нет, просто alter более опасная конструкция, чем delete/insert/select
alter - редко поддерживается транзакциями,
ошибки при использовании alter-а могут легко грохнут данные
и т.д.
права на select/insert/delete обычно дают меньше, чем на alter.
нет, просто alter более опасная конструкция, чем delete/insert/select
alter - редко поддерживается транзакциями,
ошибки при использовании alter-а могут легко грохнут данные
и т.д.
права на select/insert/delete обычно дают меньше, чем на alter.
>писец!
>и еще обсуждают же!
Я правильно понимаю, что тебе правильный ответ очевиден?
И каков же он, в таком случае?
>и еще обсуждают же!
Я правильно понимаю, что тебе правильный ответ очевиден?
И каков же он, в таком случае?
>Если его чуток подправить, то можно иметь несколько наборов этих "параметров в единственном экземпляре", скажем testing/production или еще что-то.
Угу, я об этом тоже думал.
>Ну и те преимущества, о которых уже говорили: СУБД будет следить за типизацией, за опечатками в имени...
Вот это как раз наверно не принципиально, потому что в любом из вариантов можно не давать напрямую изменять эту таблицу, а сделать набор хранимых процедур - get/set для какждого параметра.
Угу, я об этом тоже думал.
>Ну и те преимущества, о которых уже говорили: СУБД будет следить за типизацией, за опечатками в имени...
Вот это как раз наверно не принципиально, потому что в любом из вариантов можно не давать напрямую изменять эту таблицу, а сделать набор хранимых процедур - get/set для какждого параметра.
Вот ведь! Тоже вроде убедительно 
Все идет к тому, что надо каждый такой параметр уносить в отдельную таблицу 
Да здравствует реляционная теория!.. 
Все идет к тому, что надо каждый такой параметр уносить в отдельную таблицу Да здравствует реляционная теория!.. иначе, если делается трехзвенка, то получиться, что изменения/логику придется делать, как на сервере, так и в базечем это плохо?
часто разрабатывать так быстрее, проще и надежнее
ты думаешь во вором варианте не надо накатывать изменения на базу? если не накатывать, то обработка результатов запросов к такой БД усложняется. Пусть в первой версии у нас не было MAX_USERS.
также очень сильно усложняется повторное развертывание, т.е. допустим у клиента уже стоит версия - одно дело заменить только сервер, другое дело заменить сервер + корректно накатить изменения базы.
Если идти по первому варианту, то при установке второй версии надо выполнить ALTER TABLE ADD COLUMN ... DEFAULT 100. И если в приложении нам требуется узнать максимальное число пользователей, выполняем простой запрос SELECT MAX_USERS FROM TABLE1
Если идти по второму варианту, и мы не трогаем базу, то в приложении выполняем запрос SELECT VALUE FROM TABLE1 WHERE PARAM_NAME = 'MAX_USERS' и пишем следующий код: если результат содержит ноль строк, то возвращаем 100, если одну строку то возвращаем 100 (константа зашитая в коде).
А если нам надо проверить, что SERVER_NAME = 'сервер1' и MAX_USERS < 50. В первом варианте это делается простым SQL запросом SELECT * FROM TABLE1 WHERE SERVER_NAME = 'сервер1' AND MAX_USERS < 50. Во втором варианте любо сложный SQL, либо вытаскиваем SQL-ем из базы оба параметра и проверяем условие в коде.
Тут у нас еще простой исходный пример (наложено ограничение, что набор параметров существует в единственном экземпляре поэтому пример искусственный. Если это ограничение снять, и при развертывании второй версии не менять базу, то остается только сложный SQL запрос с OUTER JOIN-ом. OUTER JOIN-ы выполняются медленно, а например в MySQL их нельзя мешать с INNER JOIN-ми в одном запросе.
Налицо использование БД в целях, для которых она не предназначена.
ответ в данном случае, имхо:
нефига использовать для хранения ОДНОГО НАБОРА параметров БД - для этого есть конфигурационные файлы.
А если уж очень приспичило или НАБОРОВ у тебя несколько, то гибче и проще юзать все-таки 2-й вариант.
1-й вариант годится только если у тебя 3-4 параметра, и их кол-во в обозримом будущем не может увеличиться.
З.Ы. проектирование базы - это нечто концептуальное, и не надо менять метаданные слишком часто и без необходимости - ни одна СУБД к этому хорошо относится не будет.
Сильная фрагментация, отсутсвие оптимизации, сложность поддержки и прочие "радости".
Самый дибильный стиль проектирования системы, имхо, - это когда метаданные базы меняются самим сервером приложений. (исключение - когда в высоко-кастомизирующихся приложениях создаются и изменяются _дополнительные_ таблицы для настраиваемых сущностей).
Как пример, который мне приходилось наблюдать - есть сеть магазинов. и для товаров в каждом магазине создается отдельная таблица. А для связи "могие-ко-многим" с связанных таблицах создавалось 50 колонок с названием shop1-shop50. Т.о. кол-во магазинов в системе было ограничено 50 штуками
ответ в данном случае, имхо:
нефига использовать для хранения ОДНОГО НАБОРА параметров БД - для этого есть конфигурационные файлы.
А если уж очень приспичило или НАБОРОВ у тебя несколько, то гибче и проще юзать все-таки 2-й вариант.
1-й вариант годится только если у тебя 3-4 параметра, и их кол-во в обозримом будущем не может увеличиться.
З.Ы. проектирование базы - это нечто концептуальное, и не надо менять метаданные слишком часто и без необходимости - ни одна СУБД к этому хорошо относится не будет.
Сильная фрагментация, отсутсвие оптимизации, сложность поддержки и прочие "радости".
Самый дибильный стиль проектирования системы, имхо, - это когда метаданные базы меняются самим сервером приложений. (исключение - когда в высоко-кастомизирующихся приложениях создаются и изменяются _дополнительные_ таблицы для настраиваемых сущностей).
Как пример, который мне приходилось наблюдать - есть сеть магазинов. и для товаров в каждом магазине создается отдельная таблица. А для связи "могие-ко-многим" с связанных таблицах создавалось 50 колонок с названием shop1-shop50. Т.о. кол-во магазинов в системе было ограничено 50 штуками
MSSQLServer поддерживает alter table в транзакции, я думаю Oracle и DB2 тоже, а остальные это не базы это игрушки для извращенцев
alter - редко поддерживается транзакциями,
а остальные это не базы это игрушки для извращенцевне обижай FB
она тоже поддерживает alter'ы в транзакциях.а MSSQLServer - это такой VB среди DB
> часто разрабатывать так быстрее, проще и надежнее
не вижу - вот этих "быстрее, проще и надежнее", особенно на большем проекте, когда в проекте участвует не один человек.
> ты думаешь во вором варианте не надо накатывать изменения на базу? если не накатывать, то обработка результатов запросов к такой БД усложняется.
вот этого тоже не вижу.
я вижу, что при использование sql только как хранилища, вся работа с настройками сводится к поддержанию вот такого класса:
и при работе с этим кодом мне пофигу где эти настройки находятся в sql-базе, в xml-нике, еще где-то.
и для меня вот такой запрос в коде:
намного понятнее, чем что-то такое страшное:
ты предлагаешь sql-центрированное решение, и мне совсем не понятно - зачем мне нужна такая сильная зависимость.
не вижу - вот этих "быстрее, проще и надежнее", особенно на большем проекте, когда в проекте участвует не один человек.
> ты думаешь во вором варианте не надо накатывать изменения на базу? если не накатывать, то обработка результатов запросов к такой БД усложняется.
вот этого тоже не вижу.
я вижу, что при использование sql только как хранилища, вся работа с настройками сводится к поддержанию вот такого класса:
class Options
{
[DefaultValue("localhost")]
public string ServerName {get;set;}
[DefaultValue(100)]
public int MaxUsers {get ;set;}
}
и при работе с этим кодом мне пофигу где эти настройки находятся в sql-базе, в xml-нике, еще где-то.
и для меня вот такой запрос в коде:
if (options.ServerName='server1' & options.MaxUsers < 50)
намного понятнее, чем что-то такое страшное:
if (Convert.ToBool(Sql.ExecuteQuery ("select SERVER_NAME = 'сервер1' и MAX_USERS < 50 From Options", Options.ConnectString
ты предлагаешь sql-центрированное решение, и мне совсем не понятно - зачем мне нужна такая сильная зависимость.
> MSSQLServer поддерживает alter table в транзакции, я думаю Oracle и DB2 тоже, а остальные это не базы это игрушки для извращенцев
вот этим высказыванием - ты отрезал больше половины рынка для своего приложения.
может быть не самой платежеспособной части, но зато самой динамичной, и формирующей общественной мнение.
зы
или даже более простой пример: демки своей системы клиентам ты тоже будешь рассылать вместе с oracle-ом?
вот этим высказыванием - ты отрезал больше половины рынка для своего приложения.
может быть не самой платежеспособной части, но зато самой динамичной, и формирующей общественной мнение.
зы
или даже более простой пример: демки своей системы клиентам ты тоже будешь рассылать вместе с oracle-ом?
if (options.ServerName='server1' & options.MaxUsers < 50)сколько здесь запросов к базе?
или даже более простой пример: демки своей системы клиентам ты тоже будешь рассылать вместе с oracle-ом?c MS SQL Server 2005 Express Edition
> сколько здесь запросов к базе?
0, 1, 2 - смотря как писать код, которые стоит за этими свойствами.
0, 1, 2 - смотря как писать код, которые стоит за этими свойствами.
у Oracle тоже есть Express Edition
> c MS SQL Server 2005 Express Edition
с CD-юка без установки - он запустится?
с CD-юка без установки - он запустится?
я так понимаю пользователь этим не управляет? на что затачиваться при написании кода доступа к базе?
возможно, не проверял
и мне совсем не понятно - зачем мне нужна такая сильная зависимостьчего от чего?
> я так понимаю пользователь этим не управляет?
этим, это чем? и при чем здесь пользователь?
> на что затачиваться при написании кода доступа к базе?
ни на что, на всё, в зависимости от сферы применения, на что тебе больше нравится и т.д.
этим, это чем? и при чем здесь пользователь?
> на что затачиваться при написании кода доступа к базе?
ни на что, на всё, в зависимости от сферы применения, на что тебе больше нравится и т.д.
> чего от чего?
всей системы от наличия sql-базы, и необходимости хранения настроек в sql-базе.
всей системы от наличия sql-базы, и необходимости хранения настроек в sql-базе.
этим, это чем? и при чем здесь пользователь?пользователь класса Option
> сколько здесь запросов к базе?
вот смотри:
с точки зрения меня:
как пользователя;
как продавца;
как человека, который думает как применять эту систему,
как человека, который думает получиться или нет эту систему применить вот еще для решения такой проблемы
и т.д.
- мне пофигу сколько здесь запросов, да, хоть, 150.
но для меня является сильным ограничением:
привязка к sql-базе,
привязка к sql-базе определенных производителей,
сложность и стоимость перехода с версию на версию этого продукта,
кол-во переходов возможных в единицу времени,
требуемая квалификация людей, поддерживаемых и модифицирующих систему в дальнейшем
и т.д.
вот смотри:
с точки зрения меня:
как пользователя;
как продавца;
как человека, который думает как применять эту систему,
как человека, который думает получиться или нет эту систему применить вот еще для решения такой проблемы
и т.д.
- мне пофигу сколько здесь запросов, да, хоть, 150.
но для меня является сильным ограничением:
привязка к sql-базе,
привязка к sql-базе определенных производителей,
сложность и стоимость перехода с версию на версию этого продукта,
кол-во переходов возможных в единицу времени,
требуемая квалификация людей, поддерживаемых и модифицирующих систему в дальнейшем
и т.д.
я просто не рассматривал вариант без sql-базы
всей системы от наличия sql-базы, и необходимости хранения настроек в sql-базе.
Почти всегда база есть, поэтому о других вариантах я и не думаю А так конечно, конечно.....> пользователь класса Option
ему должно быть пофигу
т.к. если ему не пофигу - то значит наша система не переживет глобальных изменений, т.к. если даже такой код завязан на такие мелочи, то значит при глобальных изменениях придется переписывать всё.
ему должно быть пофигу
т.к. если ему не пофигу - то значит наша система не переживет глобальных изменений, т.к. если даже такой код завязан на такие мелочи, то значит при глобальных изменениях придется переписывать всё.
> я просто не рассматривал вариант без sql-базы Почти всегда база есть, поэтому о других вариантах я и не думаю А так конечно, конечно.....
по твоим планам - твой проект сколько живет активной меняющейся жизнью (месяц, год, два, пять, десять, двадцать, пятьдесят)?
что будет с проектом, если завтра, например, выпустят успешную xml-базу?
по твоим планам - твой проект сколько живет активной меняющейся жизнью (месяц, год, два, пять, десять, двадцать, пятьдесят)?
что будет с проектом, если завтра, например, выпустят успешную xml-базу?
хороший вопрос, на который я сам хотел ответить.
по твоим планам - твой проект сколько живет активной меняющейся жизнью (месяц, год, два, пять, десять, двадцать, пятьдесят)?
1-3 года, поскольку Microsoft с такой периодичностью меняет технологии.
> 1-3 года, поскольку Microsoft с такой периодичностью меняет технологии.
т.е. через 3 года скажешь пользователю bye-bye?
т.е. через 3 года скажешь пользователю bye-bye?
что будет с проектом, если завтра, например, выпустят успешную xml-базу?тут главное не выпустить, а вот будут ли ее широко использовать, в это я не верю
к слову - они уже выпущены.
и есть подозрение - что в будущем скорее всего будет связка что-то типа:
C# 3.0 + xquery + xml-база
и есть подозрение - что в будущем скорее всего будет связка что-то типа:
C# 3.0 + xquery + xml-база
> хороший вопрос, на который я сам хотел ответить.
> 1-3 года, поскольку Microsoft с такой периодичностью меняет технологии.
ты в курсе - что большинство разработок/компанией ломается как раз на переходе с одного поколения на другое?
т.к. далеко не у всех получается - как раз обеспечить простой (дешевый) переход с поколения на поколение.
причем основная причина - это повсеместная завязка на старое окружение
> 1-3 года, поскольку Microsoft с такой периодичностью меняет технологии.
ты в курсе - что большинство разработок/компанией ломается как раз на переходе с одного поколения на другое?
т.к. далеко не у всех получается - как раз обеспечить простой (дешевый) переход с поколения на поколение.
причем основная причина - это повсеместная завязка на старое окружение
т.е. через 3 года скажешь пользователю bye-bye?если бизнес успешный он оплатит новую версию с новой архитектурой
> если бизнес успешный он оплатит новую версию с новой архитектурой
либо также успешно оплатит версию конкурента, особенно если она успеет выйти быстрее, чем у тебя.
либо также успешно оплатит версию конкурента, особенно если она успеет выйти быстрее, чем у тебя.
ты в курсе - что большинство разработок/компанией ломается как раз на переходе с одного поколения на другое?заказчик должен об этом знать заранее
т.к. далеко не у всех получается - как раз обеспечить простой (дешевый) переход с поколения на поколение.
> заказчик должен об этом знать заранее
фразу не понял
фразу не понял
отлично, но вряд ли я буду использовать свой класс Option через 3 года
и есть подозрение - что в будущем скорее всего будет связка что-то типа:
C# 3.0 + xquery + xml-база
> отлично, но вряд ли я буду использовать свой класс Option через 3 года
что ты будешь использовать?
разбросанные по всему коду:
что ты будешь использовать?
разбросанные по всему коду:
if (Convert.ToBool(Sql.ExecuteQuery ("select SERVER_NAME = 'сервер1' и MAX_USERS < 50 From Options", Options.ConnectString
> отлично, но вряд ли я буду использовать свой класс Option через 3 года
какие негры и когда - это пожелание выполнят?
какие негры и когда - это пожелание выполнят?
то что переход на новое поколение заказчику обойдется дорого это надо обговаривать заранее.
> то что переход на новое поколение заказчику обойдется дорого это надо обговаривать заранее.
ты истинно веришь, что ты этим создаешь доп. конкурентное преимущество?
ты реально веришь, что продавец заказчику при попытке выиграть тендер это скажет?
ты истинно веришь, что ты этим создаешь доп. конкурентное преимущество?
ты реально веришь, что продавец заказчику при попытке выиграть тендер это скажет?
> то что переход на новое поколение заказчику обойдется дорого это надо обговаривать заранее.
это все хорошо, если тебе повезло и ты смог пробиться на рынок, ориентированный на продавцов.
но проблема в том, что большинство рынков сейчас ориентированы на покупателей.
т.е. сейчас - покупатель выбирает - это куплю, это не куплю, а не продавец/разработчик - этому продам, этому не продам.
и мне совсем не понятно - почему покупатель выбирет тот продукт, разработчики которого говорят, что завтра ему придется выложить в два раза больше, чем сегодня.
это все хорошо, если тебе повезло и ты смог пробиться на рынок, ориентированный на продавцов.
но проблема в том, что большинство рынков сейчас ориентированы на покупателей.
т.е. сейчас - покупатель выбирает - это куплю, это не куплю, а не продавец/разработчик - этому продам, этому не продам.
и мне совсем не понятно - почему покупатель выбирет тот продукт, разработчики которого говорят, что завтра ему придется выложить в два раза больше, чем сегодня.
этим конечно нет, этим наоборот. Но активным игрокам на рынке часто наплевать на дороговизну перехода на новую версию через 3 года. Им нужна система сейчас и как можно быстрее, и они готовы отбросить всё, что мешает им быстро создать систему, переносимость там всякую и т.п.
ты истинно веришь, что ты этим создаешь доп. конкурентное преимущество?
ты реально веришь, что продавец заказчику при попытке выиграть тендер это скажет?
да, но в течении этих трех лет систему конечно развивать надо, и активно, т.е. это не принцип трех
> да, но в течении этих трех лет систему конечно развивать надо, и активно, т.е. это не принцип трех
почему ты считаешь, что у тебя будет много время/денег/ресурсов на переписывание уже работающих кусков?
обычно все время уходит на создание нового функционала.
почему ты считаешь, что у тебя будет много время/денег/ресурсов на переписывание уже работающих кусков?
обычно все время уходит на создание нового функционала.
нет, я так не думаю.
почему ты считаешь, что у тебя будет много время/денег/ресурсов на переписывание уже работающих кусков?
обычно все время уходит на создание нового функционала.вот именно, нового функционала, а не подмена SQL-бызы XML-базой
> Им нужна система сейчас и как можно быстрее, и они готовы отбросить всё, что мешает им быстро создать систему, переносимость там всякую и т.п.
конечно, да.
но если ты сможешь сделать - чтобы просто было и сегодня, и чтобы просто было завтра - то ты будешь в шоколаде.
если ты сможешь предложить систему - у которой только сегодня было просто - то в шоколаде ты будешь только несколько лет.
конечно, да.
но если ты сможешь сделать - чтобы просто было и сегодня, и чтобы просто было завтра - то ты будешь в шоколаде.
если ты сможешь предложить систему - у которой только сегодня было просто - то в шоколаде ты будешь только несколько лет.
> вот именно, нового функционала, а не подмена SQL-бызы XML-базой
почему ты думаешь, что именно ты диктуешь выбор базы?
и почему ты рассчитываешь на приложение, которое работает само по себе, в отрыве от других систем?
почему ты думаешь, что именно ты диктуешь выбор базы?
и почему ты рассчитываешь на приложение, которое работает само по себе, в отрыве от других систем?
либо также успешно оплатит версию конкурента, особенно если она успеет выйти быстрее, чем у тебя.я виду речь не о программных продуктах, выставленных на рынок. А о системах, которые делаются на заказ. Переход к конкуренту будут связан с некоторыми потерями.
> вот именно, нового функционала, а не подмена SQL-бызы XML-базой
замена sql-я xml-ем, это как раз один из примеров смены поколений.
может быть именно такой смены никогда и не произойдет, но так значит будут какие-то другие смены поколений, которые тебя вынудят заняться переносом старого кода, а не разработкой нового функционала.
замена sql-я xml-ем, это как раз один из примеров смены поколений.
может быть именно такой смены никогда и не произойдет, но так значит будут какие-то другие смены поколений, которые тебя вынудят заняться переносом старого кода, а не разработкой нового функционала.
> А о системах, которые делаются на заказ. Переход к конкуренту будут связан с некоторыми потерями.
на заказ - это малоприбыльный узкий рынок.
т.к. редкий клиент - готов в одиночку нести все тяготы и риски одинночной разработки.
на заказ - это малоприбыльный узкий рынок.
т.к. редкий клиент - готов в одиночку нести все тяготы и риски одинночной разработки.
> я виду речь не о программных продуктах, выставленных на рынок. А о системах, которые делаются на заказ. Переход к конкуренту будут связан с некоторыми потерями.
примеры успешных компаний, которые занимаются такой разработкой, можешь привести?
я вижу, что в ERP-и, банках и т.д. - скорее покупают готовые системы + доработку под себя.
примеры успешных компаний, которые занимаются такой разработкой, можешь привести?
я вижу, что в ERP-и, банках и т.д. - скорее покупают готовые системы + доработку под себя.
т.к. редкий клиент - готов в одиночку нести все тяготы и риски одинночной разработки.зато рискуя он пишет систему под себя, закладывая в нее свои преимущества
>на заказ - это малоприбыльный узкий рынок.
>примеры успешных компаний, которые занимаются такой разработкой, можешь привести?
ты наверное лучше знаешь рынок, поэтому я соглашусь с тобой
>примеры успешных компаний, которые занимаются такой разработкой, можешь привести?
ты наверное лучше знаешь рынок, поэтому я соглашусь с тобой
> Переход к конкуренту будут связан с некоторыми потерями.
теперь представь, что на уровне государства, отрасли, компании - были приняты какие-то новые стандарты.
и твоя система - этим стандартам не удовлетворяет.
стандарты - могут быть самые разные:
сегодня мы все работаем с евро,
сегодня мы все работаем на linux,
сегодня мы все дружим с компанией XXX и поддерживаем ее продукты,
сегодня мы все для обмена данных используем стандарт ZZZ,
и т.д.
как долго ты сможешь удерживать клиентов от перехода на чужую разработку, которая эти стандарты поддерживает?
теперь представь, что на уровне государства, отрасли, компании - были приняты какие-то новые стандарты.
и твоя система - этим стандартам не удовлетворяет.
стандарты - могут быть самые разные:
сегодня мы все работаем с евро,
сегодня мы все работаем на linux,
сегодня мы все дружим с компанией XXX и поддерживаем ее продукты,
сегодня мы все для обмена данных используем стандарт ZZZ,
и т.д.
как долго ты сможешь удерживать клиентов от перехода на чужую разработку, которая эти стандарты поддерживает?
тут дело даже не в примерах компаний, которые уже занимаются такой разработкой. А вопрос в том, есть ли такой спрос на рынке, и на сколько он велик.
примеры успешных компаний, которые занимаются такой разработкой, можешь привести?
сегодня мы все работаем на linux,для меня это потеря клиента, но как говорится, нельзя объять необъятное....
> тут дело даже не в примерах компаний, которые уже занимаются такой разработкой. А вопрос в том, есть ли такой спрос на рынке, и на сколько он велик.
какая разница.
даже, если ты занимаешься разработкой чисто на заказ, то тогда тебе все равно выгодно, чтобы ты один и тот же код мог продать не один раз.
возьмем тот же модуль для работы с настройками: опять же интересно - его написать один раз, а потом продавать его по цене полной разработки.
какая разница.
даже, если ты занимаешься разработкой чисто на заказ, то тогда тебе все равно выгодно, чтобы ты один и тот же код мог продать не один раз.
возьмем тот же модуль для работы с настройками: опять же интересно - его написать один раз, а потом продавать его по цене полной разработки.
имхо, очень редко получается написать, что-то универсальное, что уже не написано другими, чтобы использовать в нескольких проектах
возьмем тот же модуль для работы с настройками: опять же интересно - его написать один раз, а потом продавать его по цене полной разработки.
> имхо, очень редко получается написать, что-то универсальное, что уже не написано другими, чтобы использовать в нескольких проектах
имхо, это уже зависит от твоей квалификации
имхо, это уже зависит от твоей квалификации
Пусть даже так.
А тебе будет легче переписать класс Option или перетряхивать весь код?
А тебе будет легче переписать класс Option или перетряхивать весь код?
опыт и идеи от проекта к проекту накапливаются. Но идея в новом проекте, как правило развиваются, и соответственно код переписывается. Код не такая уж большая ценность.
А тебе будет легче переписать класс Option или перетряхивать весь код?а что ты под этим подразумеваешь?
sales у вас плохие, если у программистов есть время переписывать уже работающий код
бесспорно, а также от времени, которое тебе выделали на написание этого кода
имхо, это уже зависит от твоей квалификации
Под чем - "под этим"?
"Переписать класс" - значит, переписать те один-два sql-запроса внутри него на новую систему, оставив прежним интерфейс класса - ничего снаружи класса менять не придётся.
"Перетряхивать весь код" - значит, искать по всему проекту все места, где смотрятся/обновляются настройки, и переписывать их
"Переписать класс" - значит, переписать те один-два sql-запроса внутри него на новую систему, оставив прежним интерфейс класса - ничего снаружи класса менять не придётся.
"Перетряхивать весь код" - значит, искать по всему проекту все места, где смотрятся/обновляются настройки, и переписывать их
sales у вас плохие, если у программистов есть время переписывать уже работающий кодгде я написала, что у нас есть время на переписывание кода?
"Перетряхивать весь код" - значит, искать по всему проекту все места, где смотрятся/обновляются настройки, и переписывать ихя не приводил своего кода, почему ты решил, что что-то там будет разбросано?
вот здесь:
Но идея в новом проекте, как правило развиваются, и соответственно код переписывается. Код не такая уж большая ценность.
Ты девушка или парень 
По твим постам, складывается такое ощущение, что запросы производятся каждый раз, когда мы хотим узнать какую-нибудь из настроек...
По твим постам, складывается такое ощущение, что запросы производятся каждый раз, когда мы хотим узнать какую-нибудь из настроек...
ну так он в том проекте работающий, а в новом не факт
тк правильно, а вдруг их поменяли
Это вы зря так. Многие клиенты с деньгами винду недолюбливают.
для меня это потеря клиента, но как говорится, нельзя объять необъятное....
сегодня мы все работаем на linux,
Я имею в виду, не просто осуществляется запрос к базе данных, а написана строчка, делающая этот запрос.
Сравни, что легче изменить - две строчки, или каждое место, где мы смотрим какую-нибудь из настроек
Сравни, что легче изменить - две строчки, или каждое место, где мы смотрим какую-нибудь из настроек
ты предлагаешь не программировать на .Net? или программировать на разных платформах от проекта к проекту?
Это вы зря так. Многие клиенты с деньгами винду недолюбливают.
Если .Net, то только так, чтобы всё работало и на Mono. Да, конечно, речь про системы, которые от проекта к проекту кастомизируются, а не пишутся с нуля.
чтобы всё работало и на Mono.ты так делаешь? если нет, то зачем советуешь
Я имею в виду, не просто осуществляется запрос к базе данных, а написана строчка, делающая этот запрос.нет, я не предлагал писать везде sql
Сравни, что легче изменить - две строчки, или каждое место, где мы смотрим какую-нибудь из настроек
да, так делаем.
Вообще, конечно, невозможность делать нормальные запросы к базе второй вариант губит сразу. Кроме того, в нем нельзя поддерживать ссылочную целостность и другие constraints.
Кстати, видел и такие извраты: берется объект, сериализуется в BLOB/CLOB (вариант - XML пишется в базу. У Фаулера это называется Serialized LOB. Даже имел дело с двумя жуткими системами, которые такой подход применяют
Кстати, видел и такие извраты: берется объект, сериализуется в BLOB/CLOB (вариант - XML пишется в базу. У Фаулера это называется Serialized LOB. Даже имел дело с двумя жуткими системами, которые такой подход применяют
C# 3.0 + xquery + xml-базакстати, вроде прям запросы на C# 3.0 можно писать будет, а твой класс Option он всего лишь транслятор SQL в C#, если будет универсальный транслятор, то класс Option в новой версии системы вообще не нужен
> твой класс Option он всего лишь транслятор SQL в C#
это с твоей точки зрения (как sql-центриста) - это транслятор.
с моей точки зрения - класс Option, есть штука, которая знает где брать/прятать настройки.
это с твоей точки зрения (как sql-центриста) - это транслятор.
с моей точки зрения - класс Option, есть штука, которая знает где брать/прятать настройки.
ты рассматриваешь middle-сервер, как тонкую надстройку над sql-базой.
я middlе-сервер - рассматриваю - как основное ядро системы, которое может использовать (а не может и не использовать) sql-сервер для хранения своих данных
ps
у sql-сервера - есть очень большая проблема - он очень со многими вещами просто не умеет работать.
например, не умеет работать с процессами (с действиями растянутыми во времени)
я middlе-сервер - рассматриваю - как основное ядро системы, которое может использовать (а не может и не использовать) sql-сервер для хранения своих данных
ps
у sql-сервера - есть очень большая проблема - он очень со многими вещами просто не умеет работать.
например, не умеет работать с процессами (с действиями растянутыми во времени)
это с твоей точки зрения (как sql-центриста) - это транслятор.вот не надо ярлыки навешивать
с моей точки зрения - класс Option, есть штука, которая знает где брать/прятать настройки.класс это не штука, это код на C#, почему ты C# предпочитаешь SQL-у не понятно.
Замечу, что если, действительно, по бизнесу нужна переносимоть между SQL-базой и еще чем-то, типа XML, то конечно класс нужен.
> класс это не штука, это код на C#, почему ты C# предпочитаешь SQL-у не понятно.
потому, что C# - более разностороняя среда, чем sql.
потому, что C# - более разностороняя среда, чем sql.
у sql-сервера - есть очень большая проблема - он очень со многими вещами просто не умеет работать.а middlе-сервер может всё? он может делать хранение и обработку больших объемов данных?
Если все будут переходить на новый язык - переписывать в любом случае придётся всё.
Если все будут переходить на новый способ хранения данных - тебе придётся переписывать всё, даркгрею - только одну-две строчки.
Если все будут переходить на новый способ хранения данных - тебе придётся переписывать всё, даркгрею - только одну-две строчки.
> а middlе-сервер может всё? он может делать хранение и обработку больших объемов данных?
конечно -да, работы только больше требуется.
посмотри, например, на лориен
конечно -да, работы только больше требуется.
посмотри, например, на лориен
в сегодняшнем C# у меня будет такой же класс Option
конечно -да, работы только больше требуется.а как его можно посмотреть?
посмотри, например, на лориен
он разве не open source?
а в новом MS SQL Server-е в .Net расширениях нельзя с процессами работать? хотя это уже совсем не SQL, но и писать свой серевер не надо
например, не умеет работать с процессами.
Если все будут переходить на новый язык - переписывать в любом случае придётся всё.почему? я думаю, старые сборки буду поддерживаться
> новом MS SQL Server-е в .Net расширениях нельзя с процессами работать?
и как ты себе это представляешь?
под процессом понимались "действия, растянутые по времени".
> но и писать свой серевер не надо
это самоцель?
и как ты себе это представляешь?
под процессом понимались "действия, растянутые по времени".
> но и писать свой серевер не надо
это самоцель?
это самоцель?нет, но вроде кажется, что если не писать, то получится быстрее
> нет, но вроде кажется, что если не писать, то получится быстрее
так что у тебя будет сердцем системы?
сердце - это то, что движется/живет.
sql-база - это что-то статичное.
так что у тебя будет сердцем системы?
сердце - это то, что движется/живет.
sql-база - это что-то статичное.
ок, здесь я продолжить не могу
и как ты себе это представляешь?
под процессом понимались "действия, растянутые по времени".
да, в моем понимание - система - это то, что принимает решения
ну если мыслить такими общими категориями, то почему не рассматривать sql-базу просто как часть сердца системы?
так что у тебя будет сердцем системы?
сердце - это то, что движется/живет.
sql-база - это что-то статичное.
> почему не рассматривать sql-базу просто как часть сердца системы?
а зачем?
sql-база умеет только две вещи:
надежное храние,
быструю обработку стандартных запросов поверх плоских данных.
ни то, ни другое - не является так уж всегда необходимым.
а зачем?
sql-база умеет только две вещи:
надежное храние,
быструю обработку стандартных запросов поверх плоских данных.
ни то, ни другое - не является так уж всегда необходимым.
т.е. у тебя схема базы не живет, не развивается, т.е. определяется на начальном этапе проекта и потом не меняется?
так что у тебя будет сердцем системы?
сердце - это то, что движется/живет.
sql-база - это что-то статичное.
ни то, ни другое - не является так уж всегда необходимым.что часто необходимо?
> т.е. у тебя схема базы не живет, не развивается, т.е. определяется на начальном этапе проекта и потом не меняется?
нет, конечно.
просто в идеале - схема базы вторична и определяется самим сервером, может быть прямо на лету.
нет, конечно.
просто в идеале - схема базы вторична и определяется самим сервером, может быть прямо на лету.
>просто в идеале - схема базы вторична и определяется самим сервером, может быть прямо на лету.
тогда у нас сложности с поддержкой старых данных? или серевер адаптируется на данных от предыдущей версии?
тогда у нас сложности с поддержкой старых данных? или серевер адаптируется на данных от предыдущей версии?
> что часто необходимо?
вьювер
редактор
"excel-я" подобная "математика"
сложная система запросов
ИИ
менеджер изменений
вьювер
редактор
"excel-я" подобная "математика"
сложная система запросов
ИИ
менеджер изменений
> тогда у нас сложности с поддержкой старых данных? или серевер адаптируется на данных от предыдущей версии?
что нам мешает прозрачно переконвертить данные из одной схемы в другую?
что нам мешает прозрачно переконвертить данные из одной схемы в другую?
почему до сих пор нет стандартных решений от монстров индустрии хотя бы вот этого
вьювер?
редактор
"excel-я" подобная "математика"
потому что до сих пор никто не умеет работать с настройками, когда их больше 10.
не понял
просто в идеале - схема базы вторична и определяется самим сервером, может быть прямо на лету.т.е. ты очень хочешь, чтобы схема базы данных определялась классами, а не классы определялись схемой БД?
никто в смысле из юзеров?
возьмем, например, вьювер.
Вьювер почти для произвольных данных - уже есть, надо просто соединить в кучу массу стандартных небольших кирпичиков.
но проблема в том, что все эти кирпичики надо настраивать: выравнивать по левому или по правому краю, размер сделать 100 пикселей или 120, цвет сделать черный или синий, выводить 3 цифры после запятой или 1 и т.д.
человек один (без поддержки - ИИ и менеджера изменений) не в состоянии все это настроить, или хотя бы просто удержать в голове.
ps
под ИИ понимается, например, следующее:
штука, которая знает, что для целого числа влазящего в инт - по максимуму, необходимо 11 символов.
Вьювер почти для произвольных данных - уже есть, надо просто соединить в кучу массу стандартных небольших кирпичиков.
но проблема в том, что все эти кирпичики надо настраивать: выравнивать по левому или по правому краю, размер сделать 100 пикселей или 120, цвет сделать черный или синий, выводить 3 цифры после запятой или 1 и т.д.
человек один (без поддержки - ИИ и менеджера изменений) не в состоянии все это настроить, или хотя бы просто удержать в голове.
ps
под ИИ понимается, например, следующее:
штука, которая знает, что для целого числа влазящего в инт - по максимуму, необходимо 11 символов.
> никто в смысле из юзеров?
скорее никто из "науки".
т.е. нет более-менее нормального способа/средства, который позволял бы быстро и прозрачно управлять несколькими сотнями/тысячами/миллионами/миллиардами настроек.
скорее никто из "науки".
т.е. нет более-менее нормального способа/средства, который позволял бы быстро и прозрачно управлять несколькими сотнями/тысячами/миллионами/миллиардами настроек.
> т.е. ты очень хочешь, чтобы схема базы данных определялась классами, а не классы определялись схемой БД?
и классы, и схема БД - должны определяться понятийной моделью.
понятийную модель и классы - обычно проще считать, одним и тем же, чем считать одиннаковым понятийную модель и схему БД.
и классы, и схема БД - должны определяться понятийной моделью.
понятийную модель и классы - обычно проще считать, одним и тем же, чем считать одиннаковым понятийную модель и схему БД.
ладно вьюер пока отложим, но почему это
"excel-я" подобная "математика"надо писать самим? Excel уже есть, т.е. никаких теоретических сложностей вроде нет
потому что опять все упирается в настройки.
как быть в каждом случае - с нулями (пропущенными данными с ошибками, с коллекциями.
как быть в каждом случае - с нулями (пропущенными данными с ошибками, с коллекциями.
как быть ... с нулями (пропущенными данными с ошибкамино Excel уже работает
без всякого там ИИ . Конечно, в современной системе желательно, чтобы эти вещи настраивались, но это уже мелочи. Или ты хочешь, чтобы правила работы с пропущенными данными и ошибками менялись от формулы к формуле?как быть ... с коллекциямиа вот это уже к настройкам никого отношения не имеет, это уже структура данных. Я сейчас вижу три вида структуры данных, на которых пишут формулы.
1. В Excel-е простая структура данных -- координатная плоскость -- и ее удобно изобразить на экране, но она имеет большие ограничения.
2. XML, как структура данных, предоставляет более широкие возможности (в первую очередь из-за языка навигации XPath). Но XML уже сложнее отобразить на экране. XML имеет ограничения, поскольку это все-таки дерево.
3. Реляционная (в языках типа C#, Java ее обычно называют объектной
имхо, наиболее общая структура данных. С отображением на экране еще сложнее.В первом случае формулы пишет пользователь, во втором -- полупользователь-полупрограммист (InfoPath в третьем программист.
То, что программист пишет формулы это не нравиться ни программисту (с его точки зрения это рутина ни бизнесу (составление промежуточного текстового документа, программист не глубоко вникает в бизнес и т.д.). Но в современной распределенной инфраструктуре мы не можем предоставить возможность писать формулы пользователю, поскольку вычисления могут выполняться на всех трех уровнях: на клиенте, на сервере, в БД, т.е. нет единого контекста в рамках, которого пользователь мог бы писать формулы. Сейчас нужно знать слишком много технических деталей системы, чтобы писать формулы.
Возможно, через 2-3 итерации Microsoft предоставит такую платформу.
Вапрос па теме.
Вот вы спорите, что лучше - таблица с одной строкой, но многими столбцами, или таблица с двумя столбцами и многими строчками. И никто не предложил самого логичного варианта - много таблиц с одной строкой и одним столбцом. Все достоинства обоих подходов в наличии. Ещё есть подозрение, что alter table add column сожрёт значительно больше ресурсов на табличке с дофига столбцами, чем add table.
Вот вы спорите, что лучше - таблица с одной строкой, но многими столбцами, или таблица с двумя столбцами и многими строчками. И никто не предложил самого логичного варианта - много таблиц с одной строкой и одним столбцом. Все достоинства обоих подходов в наличии. Ещё есть подозрение, что alter table add column сожрёт значительно больше ресурсов на табличке с дофига столбцами, чем add table.
кстати этот вопрос встает и когда простые данные хранить надо.
допустим есть таблица компании у нее динамическое число столбцов.
так вот проверял на MySQL и 4000000 записей что ALTER ADD Column
работает быстрее чем inner join.
а по поводу настроек провеял два способа.
в частности вопрос хранения списков
первый вариант, линейное время построение списка
<?xml version="1.0" encoding="Utf-8"?>
<Options>
<value code="somecode">somevalue</value>
</Options>
второй способ показался удобнее.
допустим есть таблица компании у нее динамическое число столбцов.
так вот проверял на MySQL и 4000000 записей что ALTER ADD Column
работает быстрее чем inner join.
а по поводу настроек провеял два способа.
в частности вопрос хранения списков
первый вариант, линейное время построение списка
--OPTIONSвторой вариант
CREATE TABLE Options (
ID_Option serial primary key,
ID_Parent int references Options(ID_Option
OptionCode varchar(50) default NULL,
OptionSubCode varchar(50) default NULL,
OptionName varchar(255) default NULL,
OptionValue varchar(255) default NULL,
OptionOrder int not null default 0
) without oids;
где значение
create table Options (
OptionId int identity,
OptionTitle varchar(255) not null,
OptionCode varchar(32) not null,
OptionVar text not null,
constraint PK_OPTIONS primary key (OptionId)
)
go
<?xml version="1.0" encoding="Utf-8"?>
<Options>
<value code="somecode">somevalue</value>
</Options>
второй способ показался удобнее.
> Excel уже работает
asm - тоже работает.
речь же идет - не о том, работает или нет, а о том, сколько ручных действий надо сделать на "единицу задачи".
> Или ты хочешь, чтобы правила работы с пропущенными данными и ошибками менялись от формулы к формуле?
конечно, да
потому, что, например, формулы
должны возвращать, в зависимости от контекста, различный результат
> наиболее общая структура данных
наиболее общая - это полноценный граф данных
> Но в современной распределенной инфраструктуре мы не можем предоставить возможность писать формулы пользователю
не вся правда
формулу вида: мат. выражения + xpath запросы - можно выполнять на любом из уровней - как на клиентском, так и на сервере, так и на уровне бд.
причем xpath - может быть даже адаптированный к работе с графом, а не только с деревом.
> вот это уже к настройкам никого отношения не имеет, это уже структура данных
как раз имеет - т.к. даже различных видов доступов на чтение к простым коллекциям набирается десятки разновидностей - последовательный доступ, доступ по индексу, доступ по ключу, общее кол-во известно/не известно, коллекция упорядоченная/не упорядоченная, фильтрация и выборка - внешние/внутрение, синхронный/асинхронный доступ, мгновенный/длительный по времени и т.д.
дальше еще больше разновидностей есть, какие изменения доступны (замены, вставки, удаления и т.д.)
далее кроме плоских коллекций - появляются деревья и графы.
asm - тоже работает.
речь же идет - не о том, работает или нет, а о том, сколько ручных действий надо сделать на "единицу задачи".
> Или ты хочешь, чтобы правила работы с пропущенными данными и ошибками менялись от формулы к формуле?
конечно, да
потому, что, например, формулы
sum(1, null, error)
2 + error
5 + null/0
x + null.y + count(error)
и т.д.
должны возвращать, в зависимости от контекста, различный результат
> наиболее общая структура данных
наиболее общая - это полноценный граф данных
> Но в современной распределенной инфраструктуре мы не можем предоставить возможность писать формулы пользователю
не вся правда
формулу вида: мат. выражения + xpath запросы - можно выполнять на любом из уровней - как на клиентском, так и на сервере, так и на уровне бд.
причем xpath - может быть даже адаптированный к работе с графом, а не только с деревом.
> вот это уже к настройкам никого отношения не имеет, это уже структура данных
как раз имеет - т.к. даже различных видов доступов на чтение к простым коллекциям набирается десятки разновидностей - последовательный доступ, доступ по индексу, доступ по ключу, общее кол-во известно/не известно, коллекция упорядоченная/не упорядоченная, фильтрация и выборка - внешние/внутрение, синхронный/асинхронный доступ, мгновенный/длительный по времени и т.д.
дальше еще больше разновидностей есть, какие изменения доступны (замены, вставки, удаления и т.д.)
далее кроме плоских коллекций - появляются деревья и графы.
Оставить комментарий
Josy
Хочу сделать в базе таблицу, в которой будет храниться некоторый набор параметров, (существующих в единственном экземпляре) и соответствующих им значений. Ну т.е., к примеру, есть набор параметров (разного типа) наподобие SERVER_NAME, MAX_USERS, CONNECTION_TIMEOUT и т.д., и надо для каждого хранить его значение. Вопрос - как лучше эту таблицу устроить.Придумал 2 варианта:
1. Создаём таблицу с числом столбцов, равному количеству параметров, при этом типы столбцов будут соответствовать типам параметров. В ней будем хранить единственный кортеж.
2. Сделаем таблицу с двумя столбцами: (param_name, param_value и будем в ней хранить пары типа (имя параметра, значение_преобразованное_в_строку). Нашёл примеры такого подхода в системных таблицах Sql Server'а.
Какие-то плюсы и минусы есть у обоих вариантов. Хочется услышать комментарии специалистов.