Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
kirkor
Member

Откуда:
Сообщений: 3
Необходимо построить ERD диаграмму по имеющемуся коду и сделать описание процедур.
1 июн 19, 16:25    [21899519]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
fkthat
Member

Откуда:
Сообщений: 1474
ППЦ, а как делать описание процедур не зная, что они делают или должны делать?
1 июн 19, 16:55    [21899535]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
kirkor
Member

Откуда:
Сообщений: 3
fkthat, Есть файл с работой и есть диаграммы классов.
1 июн 19, 17:38    [21899542]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
kirkor
Member

Откуда:
Сообщений: 3
kirkor, эти диаграммы классов связаны с кодом и по ним можно понять
1 июн 19, 17:42    [21899543]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
L_argo
Member

Откуда:
Сообщений: 943
kirkor
Необходимо построить ERD диаграмму по имеющемуся коду и сделать описание процедур.
Забей. Никто не будет влезать мозгами с нуля в большой чужой код.
Даже за небольшие деньги деньги. А больших у тебя для такой задачи быть не может.

Даже для простого проекта это трудоемкая задача.
Если сам не в состоянии это сделать, то.... см. начало этого поста. Серьезно.
1 июн 19, 20:01    [21899581]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
vikkiv
Member

Откуда: London
Сообщений: 2470
стартовая точка нужна чтобы не болтать попусту,
если не гора к Магомету то хоть в обратную сторону,
для начала зарядите ему 5млн. руб. +НДС по предоплате
со сроком сдачи в месяц, ну и дальше по убывающей
пока не найдут середину на которой сойдутся,
или вообще не придут к равновесию,
т.е. на стороне не решаемо при данных ресурсах
1 июн 19, 20:32    [21899586]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
Андрей Юниор
Member

Откуда: Москва
Сообщений: 368
1 месяц работы 1 млн руб. Ориентировочно 6-12 месяцев. Предоплата в начале каждого месяца.
2 июн 19, 00:52    [21899664]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
АСУ ТПшник
Member

Откуда:
Сообщений: 799
автор
Необходимо построить ERD диаграмму по имеющемуся коду и сделать описание процедур.

Стройте! Мы только за!
2 июн 19, 10:13    [21899724]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
L_argo
kirkor
Необходимо построить ERD диаграмму по имеющемуся коду и сделать описание процедур.
Забей. Никто не будет влезать мозгами с нуля в большой чужой код.
Даже за небольшие деньги деньги. А больших у тебя для такой задачи быть не может.
Почему, обычная работа, нанимаю человека, и он с 9 до 18 рисует ERD диаграмму по имеющемуся коду, и делает описание процедур.



kirkor,

Вы сделайте нормальное объявление:
Место работы/удалёнка.
Постоянная/краткосрочный контракт.
Ежемесечная зарплата/почасовой рейт.
Пару слов о проекте: какой код, объёмы, на каком языке (может, какая то экзотика?), ориентировочное время проекта.

А то так сложно будет кого то найти, даже координат для связи нет.
2 июн 19, 16:01    [21899823]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
L_argo
Member

Откуда:
Сообщений: 943
Почему, обычная работа, нанимаю человека, и он с 9 до 18 рисует ERD диаграмму по имеющемуся коду, и делает описание процедур.
Эффект будет около нуля. Чел скорее всего бросит на полдороги, т.к. это долгий путь.
Новый чел начнет все с начала.

На третьем круге ТС сам поймет, что затея была пустая.
Даже если какая-то диаграмма появится, она будет малополезной.
3 июн 19, 09:11    [21900109]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
L_argo
Эффект будет около нуля. Чел скорее всего бросит на полдороги, т.к. это долгий путь.
Человек бросит работу, "потому что это долгий путь"?
В первый раз такое слышу.
Десятки миллионов людей в России работают, и не собираются увольняться из за боязни долгого пути, по всем специальностям, от водителей до гендиректоров.

Потом, заголовок гласит "Доработка модели данных и SQL процедур", а визуализация модели - это какая то из частных задач.
L_argo
Даже если какая-то диаграмма появится, она будет малополезной.
Это уже другой вопрос, не для раздела "Работа".
ИМХО диаграммы в сложных системах полезны, хорошее дополнение к документации, позволяют быстро увидеть модель целиком (конечно, по отдельному модулю).
3 июн 19, 11:22    [21900226]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
L_argo
Member

Откуда:
Сообщений: 943
а визуализация модели - это какая то из частных задач.
Эта "частная" задача сложнее, чем создание самой модели данных.
А уж изучение чужой модели, а тем более производства - еще в разы сложнее.

Сразу видно, что чел ни разу не делал сабж по чужой модели а-ля "черный ящик".
Эти диаграммы - пустая трата времени. Ее могут себе позволить только богатые конторы.
3 июн 19, 14:10    [21900508]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8931
alexeyvg
L_argo
Даже если какая-то диаграмма появится, она будет малополезной.
Это уже другой вопрос, не для раздела "Работа".
ИМХО диаграммы в сложных системах полезны, хорошее дополнение к документации, позволяют быстро увидеть модель целиком (конечно, по отдельному модулю).

Мне не совсем понятно, как планируется в общем случае строить диаграмму по коду - не по собственно схеме данных, не по скрипту ее создания, а по коду процедур/классов. Если есть join двух таблиц по некоему полю - значит это внешний/первичный ключ, и пофиг что нет ограничения в схеме?
3 июн 19, 14:56    [21900564]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
L_argo
Member

Откуда:
Сообщений: 943
Мне не совсем понятно, как планируется в общем случае строить диаграмму по коду - не по собственно схеме данных, не по скрипту ее создания, а по коду процедур/классов
Никому не понятно, в т.ч. ТСу. :)

Это малореально. Ап чем собственно и весь спич.
3 июн 19, 15:17    [21900598]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
Alex Torin
Member

Откуда: Москва
Сообщений: 1078
По какому "имеющемуся коду"?
3 июн 19, 15:46    [21900630]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
Кот Матроскин
alexeyvg
Это уже другой вопрос, не для раздела "Работа".
ИМХО диаграммы в сложных системах полезны, хорошее дополнение к документации, позволяют быстро увидеть модель целиком (конечно, по отдельному модулю).

Мне не совсем понятно, как планируется в общем случае строить диаграмму по коду - не по собственно схеме данных, не по скрипту ее создания, а по коду процедур/классов. Если есть join двух таблиц по некоему полю - значит это внешний/первичный ключ, и пофиг что нет ограничения в схеме?
Да, именно так, возможно, ограничений и не создавалось.
ERD диаграмма - это же концептуальная модель сущностей, а реализация может быть какая угодно, в том числе средствами, где физически нельзя создать никаких "связей". Или можно, но разработчики придерживались концепции "констрейны только мешают" (много раз такое встречал).
Поэтому, конечно, здорово, если в обсуждаемой работе будет база с созданными fk, но, по большому счёту, единственной абсолютно достоверной и актуальной документацией любой ИС является её код.
3 июн 19, 19:09    [21900845]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8931
alexeyvg
Кот Матроскин
пропущено...

Мне не совсем понятно, как планируется в общем случае строить диаграмму по коду - не по собственно схеме данных, не по скрипту ее создания, а по коду процедур/классов. Если есть join двух таблиц по некоему полю - значит это внешний/первичный ключ, и пофиг что нет ограничения в схеме?
Да, именно так, возможно, ограничений и не создавалось.

Ну вот нарисуете Вы PK/FK на диаграмме - а на деле в данных там будут дубликаты "ключа" в первой таблице и куча мусора во второй (ибо чего бы им не быть, если физических ограничений нет). И человек, который потом воспользуется Вашей диаграммой для получения знаний о системе, станет долго поминать всех Ваших родственников до 7го колена и будет в общем-то прав.
Поэтому я согласен с L_argo - сделать-то, конечно, можно (на "отцепись"), но надо заранее понимать, что если не случится крупного везения, то на выходе получится УГ, при сдаче работы заказчик будет орать, брызгать слюнями и кидаться подвернувшимися под руку предметами - а это даже при условии полной предоплаты специфическое удовольствие.
Вот в чем пойнт, а не в том, полезны ли вообще ER-диаграммы или не очень.
alexeyvg
единственной абсолютно достоверной и актуальной документацией любой ИС является её код.

Скачайте пару примеров с чемпионатов по обфускейту и прикиньте, хотите ли ли Вы работать с такой документацией (а если хотите - то по какой ставке за разбор килобайта "документации") или ну его на.
3 июн 19, 20:48    [21900913]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58997
Блог
alexeyvg
единственной абсолютно достоверной и актуальной документацией любой ИС является её код.

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

alexeyvg
Да, именно так, возможно, ограничений и не создавалось.

Ради интереса заглянул в последний написанный сегодня мной запрос. И мгновенно обнаружил там примерно следующий момент (если выкинуть лишнее)

from
  a, b, c
where
  a.code_1 = b.code_1 and
  a.code_2 = с.code_2

-- code_1 + code_2 - первичный ключ в a
-- code_1 - внешний ключ из b, но не на a
-- code_2 - внешний ключ из c, но тоже не a
-- по любому джойну неуникальные значения будут и справа, и слева (и это правильно и так и должно быть)

В общем, при работе по такому алгоритму Вас ждёт немало сюрпризов...
3 июн 19, 21:05    [21900939]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
Кот Матроскин
alexeyvg
Да, именно так, возможно, ограничений и не создавалось.

Ну вот нарисуете Вы PK/FK на диаграмме - а на деле в данных там будут дубликаты "ключа" в первой таблице и куча мусора во второй (ибо чего бы им не быть, если физических ограничений нет). И человек, который потом воспользуется Вашей диаграммой для получения знаний о системе, станет долго поминать всех Ваших родственников до 7го колена и будет в общем-то прав.
Так зачем показывать неправильно? Нарисуйте правильную диаграмму, и никто не будет вас "поминать".
softwarer
alexeyvg
единственной абсолютно достоверной и актуальной документацией любой ИС является её код.

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

А анализ работающей системы вас не обманет, если код из модуля выполняется, то модуль используется.

softwarer
Ради интереса заглянул в последний написанный сегодня мной запрос. И мгновенно обнаружил там примерно следующий момент (если выкинуть лишнее)

from
  a, b, c
where
  a.code_1 = b.code_1 and
  a.code_2 = с.code_2

-- code_1 + code_2 - первичный ключ в a
-- code_1 - внешний ключ из b, но не на a
-- code_2 - внешний ключ из c, но тоже не a
-- по любому джойну неуникальные значения будут и справа, и слева (и это правильно и так и должно быть)
В общем, при работе по такому алгоритму Вас ждёт немало сюрпризов...
В смысле, каких сюрпризов?
Вы же понимаете, что делает этот код?
Вы понимаете, по этому коду, каким образом связаны данные в системе?
И через 10 лет, "работая по такому алгоритму", то есть прочитав этот, и остальной код вашей системы, и посмотрев данные, вы это поймёте, просто понадобится немного больше времени.
Кот Матроскин
alexeyvg
единственной абсолютно достоверной и актуальной документацией любой ИС является её код.
Скачайте пару примеров с чемпионатов по обфускейту и прикиньте, хотите ли ли Вы работать с такой документацией (а если хотите - то по какой ставке за разбор килобайта "документации") или ну его на.
Странная аналогия.
Анализировать машинные коды (или, например, байт-код джавы), и анализировать код на ЯП, с моделью БД, с данными в БД, вместе с результатами опроса бизнес пользователей, с одновременной работой с клинтским приложением - всё таки разные вещи.

Кот Матроскин, softwarer, я просто не понимаю, неужели вы так не делали?
На всех работах без исключения, где нужно было работать с существующей системой, я занимался именно этим, то есть восстанавливал модель данных по коду, разве есть другой путь?
4 июн 19, 02:47    [21901057]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
Кот Матроскин
Member

Откуда: Москва
Сообщений: 8931
alexeyvg
Кот Матроскин
пропущено...

Ну вот нарисуете Вы PK/FK на диаграмме - а на деле в данных там будут дубликаты "ключа" в первой таблице и куча мусора во второй (ибо чего бы им не быть, если физических ограничений нет). И человек, который потом воспользуется Вашей диаграммой для получения знаний о системе, станет долго поминать всех Ваших родственников до 7го колена и будет в общем-то прав.
Так зачем показывать неправильно? Нарисуйте правильную диаграмму, и никто не будет вас "поминать".

WTF "правильную"? Напоминаю - мы восстанавливаем ER-диаграмму по коду, Вам понравился метод
есть join двух таблиц по некоему полю - значит это внешний/первичный ключ, и пофиг что нет ограничения в схеме
, я продемонстрировал, к чему он приводит.
Вы знаете надежный способ восстановить ER-диаграмму только по коду (хотя бы набор необходимых и достаточных признаков первичного/внешнего ключа)?
4 июн 19, 09:44    [21901193]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2395
Кот Матроскин
(хотя бы набор необходимых и достаточных признаков первичного/внешнего ключа)?


эм... а кто сказал что FK обязателен и он есть


Кот Матроскин
Вы знаете надежный способ восстановить ER-диаграмму только по коду


и соответственно другого пути вообще нет
4 июн 19, 11:14    [21901322]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58997
Блог
alexeyvg
Нет, это документация может ввести в заблуждение

Документация может ввести в заблуждение. Люди могут ввести в заблуждение. И код тоже может ввести в заблуждение. Так и живём.

alexeyvg
А анализ работающей системы вас не обманет

Полный, тщательный и достоверный - не обманет. Только это нереально для "работающих систем" сколько-нибудь заметного объёма.

alexeyvg
, если код из модуля выполняется, то модуль используется.

Мне любопытно, как Вы проверите "код из модуля выполняется". Брейкпоинтов расставите? Но даже это не гарантирует его использование. Например, его результаты могут просто-напросто игнорироваться.

alexeyvg
Вы же понимаете, что делает этот код?

Я - понимаю. Потому что я писал этот код и я знаю стилистику своих решений. А вот Вы - понимаете? Если завтра Вы придёте на моё место - сможете только по этому селекту правильно протянуть внешние ключи?
4 июн 19, 12:18    [21901407]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3618
а всего-то чужая курсовая слизана. Код есть, а диаграммы нет. А препод придирается
4 июн 19, 15:06    [21901611]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
Кот Матроскин
Вы знаете надежный способ восстановить ER-диаграмму только по коду (хотя бы набор необходимых и достаточных признаков первичного/внешнего ключа)?
Ну, если есть поле, которое уникально, и которое не меняется, то его можно показать как первичный ключ.
Уникальность может быть определена в том числе и программным кодом (то есть не вставляем, если уже такой есть)
Или, например, она может быть определена бизнес-требованием.
Такая диаграмма адекватно покажет бизнес-модель данных.

А то, что "соглашение программистов" есть неадекватный способ обеспечения уникальности, и в таблице мусор, это есть недостаток существующей системы. Так диаграмма и рисуется, и работы инициализируются как раз для того, что бы такие ошибки поправить, данные почистить и т.д.
Кот Матроскин
WTF "правильную"? Напоминаю - мы восстанавливаем ER-диаграмму по коду, Вам понравился метод
есть join двух таблиц по некоему полю - значит это внешний/первичный ключ, и пофиг что нет ограничения в схеме
, я продемонстрировал, к чему он приводит.
Вы знаете надежный способ восстановить ER-диаграмму только по коду (хотя бы набор необходимых и достаточных признаков первичного/внешнего ключа)?
Это же ER диаграмма, а не картинка с физической моделью.
Она показывает бизнес-модель данных.
И чтение кода тут нужно для понимания, как по факту работает система, что именно хотели сделать разработчики, это, так сказать, основной итсточник знаний о том, "что есть".

Естественно, могут быть и другие варианты, например, не показывать на диаграмме такие связи, которые не укладываются в простую схему PK-FK, да ещё и гарантированные декларативно в базе (хотя непонятно, зачем такая нужна?).

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

И в таком контектсе неплохим подспорьем будет визуализация бизнес-модели данных, почему нет?
Я такое часто делал, и часто (что там часто - обычно) на диаграмме была именно бизнес модель, а данные в базе её не соответствовали, была куча мусора. Это обычно был старт работ, делал диаграммы, что бы понять модель, параллельно делая самые неотложные задачи (типа сделать бакапы, которые отсутствовали).
Большинство этим не заморачивается, но мне намного легче понимать сложные системы в визуальном виде, вот я и делаю так.
4 июн 19, 18:35    [21901819]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
softwarer
alexeyvg
Вы же понимаете, что делает этот код?
Я - понимаю. Потому что я писал этот код и я знаю стилистику своих решений. А вот Вы - понимаете? Если завтра Вы придёте на моё место - сможете только по этому селекту правильно протянуть внешние ключи?
По одному - не могу, так я и писал про анализ.

softwarer
alexeyvg
А анализ работающей системы вас не обманет

Полный, тщательный и достоверный - не обманет. Только это нереально для "работающих систем" сколько-нибудь заметного объёма.
А как иначе делают?
Приходит новый человек в банк, и за год разбирается с системой, ну или с одним модулем.
Других же вариантов всё равно нет. Либо ситстему выкидывают, либо нанимают людей, которые начинают ковыряться и разбираться.

Конкретно в ситуации ТС, система, возможно, очень сложная, а может быть, нужно будет разобраться только с интерфейсом, необходимым для создания нового модуля (то есть с теми таблицами, которые нужны для его входных и выходных данных). Без осмотра пациента не сказать.
softwarer
alexeyvg
, если код из модуля выполняется, то модуль используется.
Мне любопытно, как Вы проверите "код из модуля выполняется". Брейкпоинтов расставите? Но даже это не гарантирует его использование. Например, его результаты могут просто-напросто игнорироваться.
Ну, это уже детали. Зависит от того, насколько критично выкинуть лишнее.
Например, ищу, есть ли обращения к этому из кода клиента, а в коде клиента - вызывается ли этот код клиента каким то элементом интерфейса.
При нормальных инструментах (а то ведь некоторые "программисты" даже в файлах не умеют искать) такие поиски вполне реальны. Но, повторю, тут зависит от важности, это же, в общем то, вопрос бизнеса - сколько он за это готов заплатить, и какой навар в результате получит.
4 июн 19, 18:53    [21901835]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 58997
Блог
alexeyvg
По одному - не могу

Так именно эта фраза и вызвала вопросы что у меня, что у Кота.

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

Так в том-то и дело, что "ковыряться и разбираться", а не "код отвечает на все вопросы". Комбинировать все доступные данные и искать, с какого бока где лучше ковырнуть.

alexeyvg
Конкретно в ситуации ТС, система, возможно, ...

Конкретно в ситуации, я бы сказал что ТС невнятен, не заинтересован в результате и не выглядит сколько-нибудь адекватным и интересным вариантом приложения усилий. Есть ощущение что это что-то студенческое.
4 июн 19, 19:18    [21901866]     Ответить | Цитировать Сообщить модератору
 Re: Доработка модели данных и SQL процедур для реализация модуля управления производством  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 29315
softwarer
alexeyvg
По одному - не могу
Так именно эта фраза и вызвала вопросы что у меня, что у Кота.
Фразу "рисует ERD диаграмму по имеющемуся коду" не надо интерпретировать как "посмотрел запросик, и исчерпывающая модель данных сложной системы в голове, осталось её наривовать" :-)
softwarer
alexeyvg
Других же вариантов всё равно нет. Либо ситстему выкидывают, либо нанимают людей, которые начинают ковыряться и разбираться.
Так в том-то и дело, что "ковыряться и разбираться", а не "код отвечает на все вопросы"
"Код" я имел в виду в широком смысле, в том, как писал Стив Макконнелл, "Хороший код — наша лучшая документация".
Я, в общем, больше про то, что нельзя просто реверснуть модель из базы, и готово. Физическая модель (декраративная) может быть с ошибками. Или умышленно неполная, например, ограничения целостности проверяются триггерами, а простой автоматический реверс этого не увидит.
softwarer
Конкретно в ситуации, я бы сказал что ТС невнятен, не заинтересован в результате и не выглядит сколько-нибудь адекватным и интересным вариантом приложения усилий. Есть ощущение что это что-то студенческое.
Понятно, что kirkor что то там запулил, и исчез.
Это мы уже для себя обсуждаем, как правильно, и какой терминологией нужно пользоваться, что бы всем было понятно :-)
4 июн 19, 21:15    [21901935]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Работа Ответить