Можно позанудствовать?
Спасибо.
ById требует соблюдения некоторых соглашений. Что-то облегчили, в чем-то добавили сложности
Ваш Either не совсем та структура (монада, если угодно) Either, которая обычно используется в ФП…
Ну, и названия типа MaybeWhere глаз немного режут.
А вообще радует Ваш подход
— зло.
Можете объяснить, зачем Вам кириллица в именах?
Вот так, что без этого совсем никуда…
Если это про «национальную гордость великороссов», то представьте, что вам достался на поддержку китайский проект, а они гордыми оказались…
Про
«svoistvo»
вообще промолчу… Чем «property» не угодило? Английского не знаете?
Javascript изучаете, изучите азы английского заодно. Не трудно и пригодится много где еще.
Общее впечатление от Вашего подхода — нет структуры, каша какая-то.
Уж простите за такую критику.
Вы бы знали, сколько подобной каши я повидал…
Но дело Ваше. Чем больше пионэров, тем больше моя ценность, как специалиста.
/* Это сарказм и ирония, если что */
create table [dbo].[order]
(
[id] [int] primary key clustered,
[customerId] [int] not null foreign key references [dbo].[customer]([id]),
[deliveryAddressId] [int] not null foreign key references [dbo].[address]([id]),
[date] [datetime] not null
);
create table [dbo].[orderItem]
(
[orderId] [int] not null foreign key references [dbo].[order]([id]),
[itemId] [int] not null foreign key references [dbo].[goods]([id]),
[price] [money] not null
);
Обвязку из [customer], [address], [customerHistory] и прочего сами додумаете?
Адресов на клиента будет в среднем 1.01, имен — 1.0000000000001
Запрос тоже написать или основы поизучаете?
И да, если у Вас на таком join'е все заткнется, научите, как такого достичь?
Как-то Вы странно представляете себе реляционную модель…
Если цена меняется во времени, об этом есть записи.
Клиент сменил фамилию, об этом тоже есть запись. В Вашей модели его история потеряется
И речь шла не о преимуществах SQL, а как раз о недостатках NoSQL для представления определенных структур данных
Спасибо.
ById требует соблюдения некоторых соглашений. Что-то облегчили, в чем-то добавили сложности
Ваш Either не совсем та структура (монада, если угодно) Either, которая обычно используется в ФП…
Ну, и названия типа MaybeWhere глаз немного режут.
А вообще радует Ваш подход
— зло.
Можете объяснить, зачем Вам кириллица в именах?
Вот так, что без этого совсем никуда…
Если это про «национальную гордость великороссов», то представьте, что вам достался на поддержку китайский проект, а они гордыми оказались…
Про вообще промолчу… Чем «property» не угодило? Английского не знаете?
Javascript изучаете, изучите азы английского заодно. Не трудно и пригодится много где еще.
Общее впечатление от Вашего подхода — нет структуры, каша какая-то.
Уж простите за такую критику.
Но дело Ваше. Чем больше пионэров, тем больше моя ценность, как специалиста.
/* Это сарказм и ирония, если что */
Обвязку из [customer], [address], [customerHistory] и прочего сами додумаете?
Адресов на клиента будет в среднем 1.01, имен — 1.0000000000001
Запрос тоже написать или основы поизучаете?
И да, если у Вас на таком join'е все заткнется, научите, как такого достичь?
На RDBMS это невозможно.
Если цена меняется во времени, об этом есть записи.
Клиент сменил фамилию, об этом тоже есть запись. В Вашей модели его история потеряется
И речь шла не о преимуществах SQL, а как раз о недостатках NoSQL для представления определенных структур данных
А разве история заказов не укладывается в реляционную модель?
И вообще вся структура Клиент-Заказ-Товар.
Зачем NoSql тут?
Какие дает преимущества?
не бросайне надо смотреть в сторону Forth.Там тоже плохому научат…
Жду с нетерпением