- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
create table ISU.Н_ЛЮДИ
(
ИД NUMBER(9) not null,
ФАМИЛИЯ VARCHAR2(25) not null,
ИМЯ VARCHAR2(15) not null,
ОТЧЕСТВО VARCHAR2(20),
ПИН VARCHAR2(20),
ИНН VARCHAR2(20),
ДАТА_РОЖДЕНИЯ DATE not null,
ПОЛ CHAR(1) not null,
МЕСТО_РОЖДЕНИЯ VARCHAR2(200),
ИНОСТРАН VARCHAR2(3) not null,
ФИО VARCHAR2(80),
ДАТА_СМЕРТИ DATE default '09.09.9999' not null,
КТО_СОЗДАЛ VARCHAR2(40) default USER not null,
КОГДА_СОЗДАЛ DATE default SYSDATE not null,
КТО_ИЗМЕНИЛ VARCHAR2(40) not null,
КОГДА_ИЗМЕНИЛ DATE default SYSDATE not null
)
Мопед не мой.
PL/SQL, крупная организация.
Oracle, зачем ты разрешил кириллицу в именах полей?
Follow us!
P.S. Н_ЛЮДИ - нелюди?
Вот cмотрю я на Н_ЛЮДИ и думаю.
С этим словосочетанием у меня морг почему-то не ассоциируется. И непонятно, зачем нужен ИНН покойника.
Заплати налоги, и спи спокойно.
Иудейский б-г, в 4004-м году до нашей эры.
> Oracle, зачем ты разрешил кириллицу в именах полей?
Вопрос в самом деле загадочный. Но кириллица немного лучше, чем FAMILIYA или BIRF_DATE (вполне реальный случай). Единственный вменяемый недостаток - операторы-то не-кириллические, постоянно переключать раскладку. Так что придётся идти до конца путём 1-эс. Поехали, "ВЫБРАТЬ Таблица.ИД КАК ИД"...
Есть же иврит английский.
многовато для булина
NUMBER(3)? Oh shi...
Прочитал, как "ЗНАЕТ КАНБАН"
Знание различных методологий эджайла стало обязательным для пацанчиков на районе.
Комментарий тоже не мой :)
Потому что тогда было проще начать заново, чем сейчас. Сейчас разработчики этой штуки вроде бы и хотят изменить её, но понимают, что проще писать тонны документации и подставлять костыли, чем подготавливать гигабайтные дампы и форматировать их.
1.Где здесь автор увидел PL/SQL непонятно.
2.Не вижу никаких проблем в использовании кириллицы в именах столбцов, которые автор называет полями.
Искренне желаю автору, попасть на поддержку систему, терминов предметной области которой он не знает даже на русском.
Вероятно, стоит попросить Людмилу Павловну о дополнительных занятиях, с базами данных у вас Артём явные проблемы.
вы утверждаете, что это является аргументом в пользу кириллических имен?
PL/SQL - это оракловское расширение SQL. Вот уж не знаю, во всех ли диалектах SQL разрешены кириллические имена идентификаторов, потому указал конкретный диалект. Спецификации не читал.
> именах столбцов, которые автор называет полями
Таблицы я называю отношениями, а столбцы полями. Ничего тут уже не поделать - тлетворное влияние Дейта
> Искренне желаю автору, попасть на поддержку систему, терминов предметной области которой он не знает даже на русском.
Ну вот я, например, уже разобрался в электронном документообороте. Там я кириллические XML и парсил. Не самое приятное занятие.
> Вероятно, стоит попросить Людмилу Павловну о дополнительных занятиях,
Мы, кстати, уже обсуждали с ней этот легаси. Она-то прекрасно осознаёт, что от этого легаси хорошо бы отказаться, но система настолько громадно, что не знаешь, с какой стороны подступиться.
За время работы этой системы в ИТ кардинально поменялись многие концепции.
> с базами данных у вас Артём явные проблемы
Сказанного выше достаточно, чтобы это опровергнуть.
PL/SQL это процедурное расширение SQL и к DDL оно не имеет никакого отношения.
> Таблицы я называю отношениями, а столбцы полями. Ничего тут уже не поделать - тлетворное влияние Дейта
Другими словами, разницу между ER и табличными моделями вы также не понимаете.
>За время работы этой системы в ИТ кардинально поменялись многие концепции.
Это не имеет никакого отношения к рассматриваемому вопросу.
>Сказанного выше достаточно, чтобы это опровергнуть.
Сказанное выше это лишний раз подтверждает.
>вы утверждаете, что это является аргументом в пользу кириллических имен?
Я утверждаю, что плюсов их использования во многих случаях гораздо больше, чем минусов.
В данном же конкретном случае, автор считает возможным критиковать используемые подходы, ни капли не представляя, что это за система, как она разрабатывается и функционирует, при этом постоянно демонстрируя полное не понимание вопроса, о котором говорит.
Если человек на родном-то писать не может, пофиг, что он не сможет писать на английском, хинди или китайском. Плюс, русский язык мало подходит на самом деле для такой области. Все национальные решения - от бедности или скудоумия (на выбор).
Не очень понимаю, чем вызвана такая злость. Меня просто удивила кириллица в именах идентификаторов не в 1С и позабавила дата смерти, а Вы так реагировать стали.
Какие же плюсы получает разработчик, который не понимает термины предметной области даже на русском (согласно вашему пожеланию для автора поста)?
Я считаю, что для нетривиальных понятий нужно иметь словарь предметной области, включенный в документацию к коду приложения.
>В данном же конкретном случае, автор считает возможным критиковать используемые подходы, ни капли не представляя, что это за система, как она разрабатывается и функционирует
Добро пожаловать но говнокод!
1. Быть уволенным(ой) за то, что он(а) не смог(ла) быстро разобраться, например, в японских иероглифах в чужом коде (и комментариях к нему)
2. Медленной и мучительной смерти